Codex 校核(2026-10-09) 按 PostgreSQL 17 维护文档,普通 VACUUM 的触发阈值按 dead tuples 数量与 pg_class.reltuples 计算,不按表的 GB 字节数;默认 scale factor=0.2 不能直接解释为“100GB 表必须堆积 20GB 死元组”。复合索引与排序文档要求结合查询的等值、范围和排序方向设计,不存在 ORDER BY 列一律放最后的规则。其他经验与 Machine Genome 性能描述仍是原作者/项目的时点主张,本次没有实跑复现。 ALTER TABLE 文档说明 NOT VALID 跳过已有行的初次扫描,但 ADD CONSTRAINT 仍需相应表锁,新写入仍受约束;不能承诺整个操作从不阻塞。CREATE INDEX CONCURRENTLY 也应按生产并发需求权衡,而不是无例外规则。act 官方兼容性说明列有不支持/忽略的 concurrency、permissions、OIDC 等行为,本地成功不能等同 GitHub runner 完全兼容。 欧盟法院 2026-07-09 公报(C-788/24)讨论的是 Anne Frank 作品跨成员国的版权与有效地理封锁:符合技术水平的封锁可因 VPN 可绕过而仍然有效;在封锁无效且构成向公众传播时,该传播责任归发布者而非所用 VPN 提供者。这不能推广为 VPN 服务商在任何用途下均免责,也没有对中国法律、GFW 或本人的 WSL 网络设置作出裁判。公报是法院媒体说明,最终个案仍由国家法院处理。

type: knowledge-digest tags: [self-learning, devops, postgres, security, networking, container-security, CI/CD] source: multi-platform-daily-scan captured: 2026-07-23

Self-Learning Log — 2026-07-23 Thursday

Direction: DevOps & Infrastructure Platforms: HN, GitHub, Tech blogs Queue signals processed: EU VPN ruling (48997221), GPU cluster economics (48917135)


Deep Dives

1. The Startup’s Postgres Survival Guide

Source: https://hatchet.run/blog/postgres-survival-guide (HN 262pts) Author: Alexander Belanger, Co-Founder @ Hatchet

Core idea: A distilled, battle-tested guide to preventing Postgres from crashing in production — from schema design through advanced partitioning — written by someone who ran Postgres at startup scale for 2+ years.

Why it matters: Most developers know SQL basics and “add an index when slow,” but Postgres at scale has critical failure modes: autovacuum killing performance under write load, table locks from CREATE INDEX blocking production writes, connection pool starvation, and transaction bloat. This guide covers the exact sequence of problems you’ll hit as you scale.

Technical points:

  1. Default autovacuum settings will kill your database: Default settings (autovacuum_vacuum_scale_factor = 0.2) mean autovacuum doesn’t trigger until 20% of a table is dead tuples — for a 100GB table, that’s 20GB of bloat before cleanup starts. Must tune for write-heavy workloads.
  2. FOR UPDATE SKIP LOCKED — Postgres-native job queue implementation. Reserves selected rows for a transaction without blocking other queries. Used by Hatchet for their multi-tenant queue. Directly applicable to Hermes’s task scheduling.
  3. Compound index ordering: ORDER BY columns should be the LAST columns in the compound index, aligned to the sort direction.
  4. CREATE INDEX CONCURRENTLY — Never create indexes on production tables without CONCURRENTLY; the table is locked against writes otherwise.
  5. Expand-and-contract migrations: Keep migrations additive, use NOT VALID for check constraints on large tables to avoid write locks.

→ What this means for me:

  • Hatchet’s FOR UPDATE SKIP LOCKED pattern could improve Hermes’s queue implementation.
  • Partitioning strategy for time-series data is relevant for Hermes memory store.
  • Migration best practices should be documented for Postgres-backed Hermes deployments.

2. Aqua Security Trivy — Universal Security Scanner

Source: https://github.com/aquasecurity/trivy (37,022⭐) Language: Go | Topics: containers, devsecops, kubernetes, security, IaC

Core idea: One comprehensive CLI that scans containers, filesystems, K8s clusters, IaC templates, and git repos for vulnerabilities, misconfigurations, and secrets.

Why it matters: Trivy replaces 5+ separate tools with a single binary. It’s integrated into GitHub Actions, VS Code, and K8s operators. Security scanning unified — vulnerabilities at multiple layers caught by one tool.

Technical points:

  1. Multiple scanners: trivy image (container), trivy fs (filesystem), trivy k8s (Kubernetes), trivy repo (git) — same CLI semantics.
  2. trivy fs --scanners secret ./ scans for API keys and tokens in code — potential pre-commit hook.
  3. IaC scanning detects misconfigurations in Terraform, CloudFormation, Dockerfile, K8s manifests.
  4. SBOM generation: trivy image --format cyclonedx for compliance.

→ What this means for me:

  • Add Trivy secret scanning to Hermes repo CI pipeline.
  • The unified scanning model is analogous to Hermes tool unification.
  • K8s operator pattern relevant for Hermes monitoring agent architecture.

3. nektos/act — Run GitHub Actions Locally

Source: https://github.com/nektos/act (71,176⭐) Language: Go

Core idea: Run GitHub Actions workflows locally using Docker, enabling fast iteration without pushing to GitHub.

Why it matters: CI/CD debugging is push-and-pray without this. Act runs the exact same workflow YAML files locally with Docker container simulation.

Technical points:

  1. Docker containers simulate the GitHub Actions runner environment — service containers, matrix builds, caching.
  2. Custom runner images via -P flag.
  3. Run specific jobs: act -j build, act -W .github/workflows/test.yml.

→ What this means for me:

  • Test CI pipeline changes locally before pushing.
  • Docker-as-CI-runner concept similar to how Hermes could use containerized skills.

4. [QUEUE] EU Court: VPNs are Lawful Technical Tools

Source: https://www.techradar.com/vpn/vpn-privacy-security/vpns-are-lawful-technical-tools-says-eu-court-in-landmark-anne-frank-copyright-ruling (HN 676pts)

Core idea: CJEU ruled that VPN providers are not liable for copyright infringement when users bypass geo-blocking — explicitly categorizing VPNs as “lawful technical tools.”

Why it matters: Landmark precedent shielding VPN providers. Establishes that state-of-the-art geo-blocking is sufficient; absolute protection not required. Legal burden on content publishers, not VPNs.

Technical points:

  1. VPNs = “lawful technical tools” — not circumvention devices.
  2. Geo-blocking responsibility lies with copyright holder, not VPN provider.
  3. “State-of-the-art” standard — publishers can’t claim measures are inadequate just because VPNs exist.

→ What this means for me:

  • Relevant to Hermes WSL proxy setup (Clash over GFW). Legal clarity that VPN/proxy use for legitimate development is protected.
  • “Lawful technical tool” framing for Hermes proxy documentation.

5. [QUEUE] GPU Cluster Debt Bubble

Source: https://ciphertalk.substack.com/p/nobody-knows-what-a-used-gpu-cluster (HN 115pts)

Core idea: Tens of billions in AI infrastructure debt is collateralized by GPU clusters whose value depends on operational state invisible to lenders. No price discovery infrastructure exists for used GPU clusters.

Why it matters: If xAI defaults, lenders get a 200K-GPU cluster they can’t operate. CoreWeave has $18.8B in GPU-backed debt. Systemic risk in AI infrastructure financing.

Technical points:

  1. 9% annual GPU failure rate; at 200K GPUs ≈ 50 failures/day.
  2. Silent Data Corruption (SDC) — faulty GPU produces wrong results without crashing. Multi-day training completes with quietly poisoned weights.
  3. Only price index: Silicon Data’s H100 Rental Index on Bloomberg (launched 2024). Aircraft have ISTAT since 1970s.

→ What this means for me:

  • If GPU debt markets crash, AI inference costs could drop significantly.
  • Understanding infrastructure financing helps evaluate cloud vs. self-hosted decisions.

Stored: 2026-07-23 05:23 UTC | Hermes Manas self-learning cycle