← All digests

DBMS Weekly — 2026-08-31 (week of Aug 31–Sep 6)

This was the week the LLM bug-hunting wave stopped being an anecdote and became the tree's main input. Noah Misch ran an LLM over FOR PORTION OF and handed Paul Jungwirth twelve distinct defects, which he filed as eleven separate -hackers threads in a single sitting on Sept 4. Thom Brown "set Claude on a mission" against REPACK (CONCURRENTLY) and got a reproducible logical-decoding segfault. Zsolt Parragi's "claude feature-crosscheck analysis" turned up a permanent table's foreign key pointing at an unlogged partition — with pgbench itself as the accidental user of the bug. And on Sept 4 Nathan Bossart opened a proposal to release minor versions more often, motivated in his own words by "the recent influx of bug reports." Meanwhile Dimitri Fontaine independently reproduced four of the five design problems behind last week's MERGE/SPLIT PARTITION(S) revert on a Beta 3 build, and noticed the release notes still advertise the feature. The CommitFest queue rolled over — PG20-3 (#62) is now the open one — and two commits were reverted within days of landing. Outside the tree, VLDB 2026 ran in Boston across most of the window, MariaDB shipped B-link-style concurrent InnoDB page splits at 5.2x insert throughput, and a paper measured 992-out-of-1000 stale reads against PG 19's WAIT FOR LSN alternative.

PostgreSQL

  • Getting Ready for PostgreSQL 19 — the most useful thing published about 19 so far, every claim run against a 19beta3 image. The compatibility list is the part to read twice: JIT off by default, standard_conforming_strings forced on with no server-side escape (old dumps won't load), RADIUS auth removed, the inet/cidr GiST default opclass moved out of btree_gist into core because the old one could omit qualifying rows (pg_upgrade refuses until you REINDEX), and max_locks_per_transaction going 64→128 because the lock allocation size changed — so a tuned value must be doubled to keep the same capacity. Then a bonus: he reproduced four of the five problems behind the MERGE/SPLIT PARTITION(S) revert on Beta 3 (a partition CHECK constraint vanishing after a merge; a stored generated column silently recomputed, 26 → 1300; logical decoding emitting bare INSERTs with no matching DELETEs; a publication naming a merged partition quietly replicating nothing) and notes the release-note source, edited Sept 1, still lists the feature five days after Alexander Korotkov ripped it out. (Dimitri Fontaine · tapoueh.org)
  • Read your own writes, off the primary — 1,000 write-then-read cycles against a 19beta3 primary/async-replica pair: naive replica reads were stale 992 times out of 1,000. Sticky-to-primary lands at p50 1.9 ms, a blind sleep 50ms at 53.9 ms, and PG 19's WAIT FOR LSN at p50 2.8 ms / p99 6.4 ms with zero stale reads. The nuance most people get wrong: synchronous_commit = on plus synchronous_standby_names waits for flush, not replay, so it only gets staleness down to 3–17 per 600. Also documents the TIMEOUT fallback curve, the in-transaction pg_current_wal_insert_lsn() trap (verified with pg_get_wal_records_info — a 40-byte gap is one 34-byte Transaction/COMMIT record), the READ COMMITTED restriction, and a real ActiveRecord bug where the leading-keyword allowlist classifies WAIT FOR as a write. Repo included; one anomaly honestly flagged as unreproducible. (Radim Marek · boringsql.com)
  • What Replica Mode Does Not Switch Offsession_replication_role = replica is widely described as "turning enforcement off," and the transcripts show otherwise: CHECK, NOT NULL, UNIQUE, identity columns and row-level security all keep refusing rows, while foreign keys, ON DELETE CASCADE, rules and event triggers go quiet — and a trigger marked ENABLE REPLICA fires for the first time in its life. Two orphans end up in the table with pg_constraint still reporting convalidated t, and VALIDATE CONSTRAINT against an already-valid constraint returns success without reading a row. Of the three levers, only ALTER CONSTRAINT ... ENFORCED re-scans on the way back — and a forced RLS policy can hide rows from that scan, so it "succeeds" on a table that still holds violations. Run on 18.6 and 19beta3, output pasted as it came back. (Mikhail Shytsko · seedfa.st)
  • pg-catalog-almanac — a browsable diff of pg_catalog across 9.6→19, all 143 documented relations. Findings straight out of the dataset: 19 beta 3 adds 12 catalogs/views and 43 columns, the largest addition in that whole span (five of them SQL/PGQ, plus pg_stat_lock, pg_stat_recovery, pg_stat_autovacuum_scores and progress views for REPACK and online checksum changes); exactly one relation has ever been removed (pg_pltemplate, gone in 13); and the collation-metadata churn — collcollate/datcollate going nametext in 15 to escape the 63-byte identifier limit for long ICU locales, then colliculocale → provider-neutral colllocale in 17. Useful if you maintain version-portable monitoring queries. (Richard Yen · richyen.com)
  • New system views in PostgreSQL 19 — hands-on tour of pg_stat_lock (including fastpath_exceeded and why it points at max_locks_per_transaction), pg_stat_recovery's atomic snapshot, and 19's scored autovacuum prioritisation with the arithmetic worked out rather than asserted. (Gülçin Yıldırım Jelínek · ClickHouse)
  • All Your GUCs in a Row: log_lock_waits and log_lock_failures — the daily GUC series ran through seven more logging parameters this week; this is the one with a recommendation attached. log_lock_waits is the cheapest heavyweight-lock-contention detector the server ships and it has been off by default through 18 — 19 turns it on for you. The rest of the week: log_min_messages/log_min_error_statement/log_error_verbosity, log_parameter_max_length, the sampling trio, log_replication_commands, log_startup_progress_interval/log_recovery_conflict_waits, and the four *_stats counters. (Christophe Pettus · thebuild.com)
  • PostgreSQL RPM repo comes to Amazon Linux 2023! — AL2023 becomes a first-class PGDG YUM target (x86_64 and aarch64 for Graviton) with core, contrib, devel, the PLs, ODBC and the pooling/backup/replication/monitoring set populated from day one. The gaps are stated plainly rather than buried: the whole GIS stack is not built for AL2023 because Amazon Linux has no EPEL equivalent, and Patroni is absent until its dependency chain can be built. (Devrim Gündüz · PGDG packager) [by maintainer]

PostgreSQL mailing lists

588 messages on pgsql-hackers in the window across all seven days, 63 of them new threads; 58 on pgsql-bugs; pgsql-performance was silent.

  • [hackers] FOR PORTION OF bugs — "Noah Misch found a number of new FOR PORTION OF bugs with some LLM investigation. I've attached the original prompt and findings." Twelve defects (D1–D12), filed the same day as eleven further threads so each can be reviewed independently: bounds not coerced in PREPARE, EXPLAIN (GENERIC_PLAN) failing with no value found for parameter 1, EXPLAIN actually evaluating the bound expressions, bounds evaluated more than once (so a mis-declared STABLE function gives inconsistent results), statement-level insert triggers for temporal leftovers firing against the parent under plain inheritance, a DO INSTEAD rule skipping the leftover insert, and a WITH CHECK OPTION failure blaming the leftover instead of the original update. 19's headline temporal feature, eight weeks from GA. (Paul A Jungwirth · pgsql-hackers) [patch posted]
  • [hackers] REPACK (CONCURRENTLY) can crash a logical decoding session — "I have been test-driving repack in an attempt to break it. I had no luck, but I set Claude on a mission." A backend decoding the transaction a concurrent REPACK produced segfaults on a non-assert build at both wal_level = replica and logical; the assert build trips Assert("change->data.tp.newtuple") one frame earlier. The reproducer needs a large incompressible value so the UPDATE writes a new out-of-line TOAST datum. Follows Nathan Bossart's eight-bug REPACK haul from last week, plus two more this week: invalid indexes, and the decoding worker being cancelled by lock_timeout. (Thom Brown · pgsql-hackers) [open]
  • [hackers] proposal for a new minor release schedule — "Given the recent influx of bug reports, I am proposing that we release minor versions of PostgreSQL more frequently." Three concrete options on the ballot, two of which add two releases a year (six total); already discussed on security@, pgsql-release@ and pgsql-packagers@, now open to the community before a pgsql-release vote. The stated hope is that a tighter cadence also makes out-of-cycle releases a rarer judgement call. (Nathan Bossart · pgsql-hackers) [open]
  • [hackers] Protocol compression: a fourth design — three previous attempts each showed real traffic reductions and each accumulated the same unanswered questions: negotiation, I/O layering, codec and direction selection, poolers, compress-before-encrypt. This design narrows the surface deliberately — Zstandard only, an explicitly negotiated _pq_.compression=zstd extension, compression starting only after authentication and the first ReadyForQuery, and only DataRow/CopyData server-to-client and CopyData client-to-server. Query, Parse, Bind, parameters and all control messages stay ordinary uncompressed protocol messages, so a pooler can still read them. (Andrey Borodin · pgsql-hackers) [patch posted]
  • [hackers] Direct TOAST v2, faster, smaller and no migration needed — replaces the TOAST pointer's 32-bit OID plus B-tree index lookup with direct physical TID addressing, attacking write amplification, index contention and read latency in one go; presented as a subtype of ordinary TOAST rather than a parallel mechanism, so a cluster can switch to it and back with no migration. The author's own honest note: he hoped for less code, and the new b-tree-in-toast-table means it isn't. Michael Paquier landed the groundwork rename (varatt_externalvaratt_external_oid) in the same window. (Hannu Krosing · pgsql-hackers) [patch posted]
  • [hackers] Reducing relcache memory usage: deduping index shapes — a btree on a bigint column has the same rd_opfamily, rd_opcintype and rd_support as every other btree on a bigint column, and the relcache allocates all of it per index. The patchset adds a dedup layer so equivalent key definitions share one set, plus Andres Freund's ProxyContext — which forwards small long-lived allocations straight to malloc instead of paying aset.c's per-context overhead. Follow-up to the author's PGConf.dev talk. (Matthias van de Meent · pgsql-hackers) [patch posted]
  • [hackers] gist_trgm_ops '=' operator: planner picks it over btree, ~300x slower — with both a btree and a gist_trgm_ops index on the same text column, a plain equality query can get the GiST plan: 1,583 buffer hits and 15.2 ms to return zero rows on a 100k-row table. David Rowley reported the identical problem in September 2024 and got no replies; this time it comes with three candidate patches. (Vaibhav Dalvi · pgsql-hackers) [patch posted]
  • [hackers] Prevent foreign key references to unlogged partitions — "another find with my claude feature-crosscheck analysis." The FK persistence check only looks at the relation named in the constraint; a partitioned table is always permanent, but its partitions need not be, so a permanent table's foreign key can end up referencing unlogged data. The bug already has a user in the tree: pgbench --partitions --unlogged-tables silently ignores the unlogged flag for top-level tables but creates pgbench_accounts' partitions unlogged, and those are referenced by permanent tables. (Zsolt Parragi · pgsql-hackers) [patch posted]
  • [hackers] [PATCH] Corruption Issue: Fix missing tts_tid in ExecForceStoreHeapTuple — a KNN GiST scan with lossy distance recheck loses the tuple's ctid when tuples come off the reorder queue, and under SELECT ... FOR UPDATE the invalid TID (4294967295, 0) reaches heap_lock_tuple(). Because InvalidBlockNumber equals P_NEW, ReadBuffer() extends the relation on disk before aborting — leaving an orphaned uninitialised block that then fails every sequential scan with invalid page in block N. Affects 14 through master. (Virender Singla · pgsql-hackers) [patch posted]
  • [hackers] [RFC PATCH] Cost-based delayed projection for ORDER BY ... LIMITmake_sort_input_target() already postpones a target expression past a top-N sort when that one expression costs more than 10 * cpu_operator_cost, but never considers a target list of several individually cheap expressions that are expensive in aggregate. On a million rows the difference between the automatic plan and the hand-written subquery form was 95 ms vs 15 ms. (ChenhuiMo · pgsql-hackers) [patch posted]
  • [bugs] BUG #19649: Qual pushdown into GROUP BY subqueries ignores non-equivalence-preserving references — when an outer WHERE references a grouping column through a coercion (::text, j->>0), the qual is pushed below the grouping node even though it applies a different equivalence relation than the grouping does, splitting one group in two: counts change, rows are lost, and the same subquery group answers with two different group keys under two different outer WHEREs — impossible under SQL semantics. Richard Guo committed a fix for the sibling CASE-over-DISTINCT case in the same window. (chunling qin · 18.6) [open]
  • [bugs] to_date()/to_timestamp()/to_number() silently accept or truncate out-of-range input — three reports filed the same day by the same person. to_date('2024 1000', 'YYYY DDDD') keeps only the first three digits and returns 2024-04-09; IDDD 999 is accepted although an ISO year has at most 371 days; SSSSS, RM and IW accept out-of-range values; to_number() truncates over-length integers. The docs promise an error in every one of these cases. (chunling qin · #19651, #19652) [open]
  • [bugs] BUG #19654: JSON_EXISTS returns the ON ERROR value for SQL NULL after a prior error — once an earlier row of the same compiled expression has taken the ON ERROR path, a later SQL NULL input gets the ON ERROR replacement instead of NULL, so scan order changes the result. Reproduced on 18.6 and 19beta3 with default config. (Ce Lyu) [open]
  • [bugs] BUG #19653: "variable not found in subplan target list" during planning — a four-condition planner failure: an unanalyzed right-hand table pushing the planner to a parameterized nested loop, parallelism enabled with very low cost parameters, GROUP BY ROLLUP producing a MixedAggregate that trims the child targetlist, and an inner index-scan filter referencing both outer and inner columns. Fails at plan construction, not execution; the non-partitioned equivalent works. (Annie · ECNU · 18.6) [open]
  • [bugs] Do we want to avoid checksumming extra files in the datadir? — a third-party extension drops pgactive.stat into global/ and pg_checksums fails trying to parse the filename. Escalated from BUG #19647 with the actionable half isolated: PG 17 relaxed this for pg_basebackup and not for pg_checksums, which is hard to defend either way. (Jacob Champion · pgsql-hackers) [open]
  • Also filed this weekReport relation extension blockers within parallel lock groups (Bertrand Drouvot); logical decoding: skip unnecessary snapshot distribution (yangboyu, Alibaba); Temporal foreign key actions (Paul A Jungwirth); Teach pg_upgrade to deal with invalid databases (Bharath Rupireddy); Assert failure in try_nestloop_path() (Richard Guo); and Add require_wal_receiver connection parameter to libpq (Jim Jones).

What landed (pgsql-committers)

150 messages, 64 distinct commit threads in the window.

CommitFest (open: PG20-3, #62)

  • Queue rolled over this week. PG20-2 (#61) moved to In Progress (its review month runs to Sep 30) and PG20-3 (#62) is now the open CF — new patches land there. #62 already holds 44 entries (32 needs review · 7 ready for committer · 3 moved · 1 withdrawn) after a few days.
  • Balance for #61 (PG20-2): totals as of Sep 7 — 287 needs review · 26 waiting on author · 70 ready for committer · 81 committed · 34 moved · 20 withdrawn · 1 rejected · 1 returned — 520 total. (vs last week's 506: total +14, but the shape moved a lot — needs-review −25, ready-for-committer +14, committed +13, moved-to-next-CF +11. The In Progress month is doing what it's supposed to.)
  • New this week (visible portion, Sep 1–6): 25 records created in #62. Standouts: Direct TOAST v2 (Hannu Krosing) — see above; Native planner and executor for SQL/PGQ (Henri Gasc) — replacing the current graph-query rewrite with a first-class planner/executor path; plus Teach pg_upgrade to deal with invalid databases (Bharath Rupireddy), Avoid checksumming extra files in the datadir (Jacob Champion), glist: _Generic wrapper for selective dlist/dclist usage (Matthias van de Meent), Honor WAL insertion clamp in XLogBackgroundFlush, and Fix races in Windows pthread emulation (Nazir Bilal Yavuz).
  • Closed (visible portion): committed — auto-vectorize varbit bitwise operators, Fix WAL block image length diagnostic, Backup manifests accept out-of-range LSNs, Unsafe qual pushdown through DISTINCT with simple CASE expressions, initdb: Pad rewritten GUC lines with spaces, not tabs, fix autovacuum scoring corner case, Remove dead code in pg_dump, Test coverage for pg_clear_attribute_stats() null arguments; withdrawn — LockHasWaiters() crashes on fast-path locks, Fix autovacuum freeze bug where weight can lower a table's freeze score.
  • Coverage caveat, as every week: both activity logs cap at ~100 rows with no pagination, and this Monday capture reaches back only to Sep 1 ~16:30 — Aug 31 and Sep 1 morning are invisible. The queue-total delta is the reliable week-over-week number.

Community pulse

A genuinely dead week on Hacker News for databases: across ~331 in-window stories above 8 points plus keyword sweeps, the highest-scoring DB item was "Reverse engineering the storage format for an undocumented database" at 43 points and 3 comments. DBA Stack Exchange had four questions all week, top score 1. The argument moved to Reddit and Lobsters.

  • "A Better SQL in 11 Lines" gets taken apart — a new language pitched itself against a deliberately ugly 20-line SQL query; the top comment rewrote the same thing in 12 lines of ordinary INNER JOIN, a second noted that has been the obvious spelling for thirty years, and the thread deflated entirely when someone checked the repo and found the language doesn't compile to SQL and doesn't run on any existing engine. The week's most efficient debunk. (Lobsters · 45 pts, 12 comments)
  • Where do you actually write down what a column means?COMMENT ON vs dbt config vs version-controlled DDL vs the stale Confluence page. The objection to COMMENT ON wasn't that it's wrong but that it's invisible in the tools people work in; the r/PostgreSQL companion thread landed the cleaner rule (COMMENT ON for durable object description, -- for explaining the migration) and surfaced a genuinely new argument for it: descriptions in the catalog measurably improve an LLM's schema comprehension and cut token usage versus an external doc file. (r/SQL · 34 pts, 64 comments; r/PostgreSQL · 14 pts, 21 comments)
  • How do you prove a column is safe to drop? — ~20 suspected-dead columns on a 60-column Postgres table with invisible consumers in Metabase, Retool and notebooks. Consensus was the reversible scream test (rename first, or snapshot, and strip it from the view layer before the table), with a structural dissent that the whole problem is self-inflicted by granting direct table access instead of routing through views, and a minority pointing out that something may still be writing to it. (r/SQL · 26 pts, 37 comments)
  • AI is really freaking me out — the biggest data thread of the week by a distance, and the sub talked the OP down almost unanimously: the 581-point top reply argues that if your bread and butter is coding rather than modelling and connecting data, that part goes — with a strong secondary current predicting a lucrative market in undoing AI-generated pipelines. (r/dataengineering · 390 pts, 212 comments)
  • One honesty note: four of the highest-comment r/SQL threads this week share a near-identical template (lowercase philosophical title, "Postgres 15, X downstream" framing, abstract hook), two share an author, and one account registered the day it posted. The comments are clearly real practitioners; the prompts may not be. Read the discussion, not the question.

Wider DBMS & distributed data

  • VLDB 2026 — Boston, Aug 31–Sep 4 — the 52nd VLDB ran across almost the whole window. Best Research Paper went to Garnet: A Next-Generation Cache-Store for Accelerating Applications and Services (Badrish Chandramouli et al., Microsoft); honorable mentions include How to Write to SSDs (Bohyun Lee, Tobias Ziegler, Viktor Leis, TUM) and CMU's Demystifying and Improving Lazy Promotion in Cache Eviction. Test of Time went to Google's Dataflow Model paper; Early Career to Jana Giceva (TUM). (VLDB Endowment)
  • No more allocation delays: decoupling snapshots from shard relocation in stateless Elasticsearch — snapshots stream from object storage instead of pinning primary shards in place, which is the whole reason shard relocation used to stall behind a backup. Fleet-wide numbers: "undesired allocation due to snapshot" warnings to zero, cache misses down over 60%, median cache-population throughput up ~50%. (David Turner, Yang Wang · Elastic)
  • What is a Neki router? — the Vitess authors describing their Postgres sharding router: a two-plan model surfaced through a new EXPLAIN (NEKI_PLAN) that distinguishes Route[EqualUnique] from Route[Scatter] + Collapse, and a router that terminates the Postgres wire protocol itself rather than sitting behind PgBouncer. (Andres Taylor, Harshit Gangal, Ahmed Darwich · PlanetScale)
  • Pipelined SQL in ClickHouse 26.8 — first ship of the |> pipe operator, with EXPLAIN SYNTAX showing exactly how each stage desugars into nested SELECTs and, more usefully, where stage ordering silently changes the result. A datapoint in the wider SQL-pipe-syntax movement rather than a feature sheet. (Mark Needham · ClickHouse)
  • Parquet and Iceberg: how a table format builds on a file format — names the non-obvious traps rather than the layer cake: Iceberg has no partition projection by design, and PyIceberg downcasts nanosecond timestamps where the JVM path does not. (Javier Ramirez · QuestDB)

Commercial engines (SQL Server, Oracle, MySQL, …)

  • From a Chocolate Wrapper to Concurrent InnoDB Page Splits — B-link-style concurrent page splits that drop InnoDB's index-wide structure-modification latch: 19,676 → 102,838 inserts/s (5.23x) with p95 falling from 8.28 ms to 0.56 ms. Includes the mtr_t::transfer_to() latch-ownership mechanism that makes it work and an honest list of what the prototype still can't do. The strongest engine-internals post of the week in any engine. (Roman Nozdrin · MariaDB Foundation)
  • Avoiding and correcting hotspots: how Elasticsearch Serverless balances shards — replaces classic node-weight rebalancing with resource-usage-aware allocation to kill index-shard colocation, OOMs and write hotspots. An allocator redesign written up as one, not a release note. (Dianna Hohensee · Elastic)
  • PostgreSQL INCLUDE indexes: what problem are they trying to solve? — a pageinspect-level walk through B-tree pivot tuples showing that INCLUDE columns are payload, not key space; why the feature exists at all (enforcing a unique constraint without needing an operator class for the extra column); and the cost nobody mentions — deduplication is disabled outright on an index with INCLUDE columns. (Franck Pachot · dev.to)
  • MariaDB Connector/C compatibility: an update on CONC-821 — root-cause of a maintenance-release regression where mysql_stmt_bind_result() stopped preserving caller-supplied length values, which made temporal values look absent to Qt applications and to the Diesel Rust ORM. (Frédéric Descamps · MariaDB Foundation)
  • Mongorewind: rewind test data without restoring a backup — builds an undo log from a cluster-wide change stream with changeStreamPreAndPostImages and replays inverse operations in reverse; the operation→inverse mapping table is the actual content and the part that generalises. (Zelmar Michelini · Percona)

Migration experience

  • Migrating a Redis cluster across clouds without chaos — moving a Jedis service AWS→Alibaba without a Kafka-wide backfill put every read across clouds at 5–10 ms against a 75 ms SLA. The cloud-aware slot-map patch then broke three separate ways: it ignored cross-cloud master promotion, non-contiguous slot ranges like "1-3096,4078" crashed startup, and one TreeSet per slot instead of per shard blew up memory. (charanvasu.com)
  • Upgrade took 1 hour. Preparation took 2 months. — a nine-major-release Open edX jump where squashed Django migrations made release-skipping impossible (a throwaway Docker image per release just to run migrate), converting every MySQL table to utf8mb4 was the single longest step, and a 500 GB MongoDB turned out to be course videos parked in GridFS. Mild vendor angle — the author's company hosts the result — but the detail is lived, and corroborated in the Open edX forum thread. (Andrés González · Aulasneo)

Research & cutting edge

  • Aker: Density-Aware Approximate Caching for Vector Search — built directly into pgvector: a per-query adaptive similarity threshold plus a "del-consistency" model (eager deletes, lazy inserts) gives +64 recall points and 3.2x QPS at 0.6x the memory of pgvector's shared buffers. (Oh, Kang, Kim, Lu, Liu, Zhang, Chen, Won · KAIST + Microsoft Research, PVLDB 19(10), Sep 3) [paper]
  • A Power Law in Logarithm's Clothing: On the Scalability of Graph-Based Vector Search — refutes the folk claim that HNSW/Vamana search cost is poly-logarithmic in N: below a size threshold set by intrinsic dimensionality it grows as N^c, and that regime is where most real pgvector indexes actually live. Comes with models predicting the exponent per recall target. (Faghfoor Maghrebi, Eslami, Dayan · Sep 2) [paper]
  • Poisoning Attacks on the PGM-index — adversarially inserting 10% of keys inflates the PGM-index's segment count, and therefore its size, by up to 120x, with a proven upper bound showing the attack is near-optimal. A concrete argument against shipping learned indexes on attacker-influenced key distributions. (Sato, Aumüller, Matsui · Sep 2) [paper]
  • Detecting DBMS bugs by constructing equivalent representations of intermediate query results — a metamorphic oracle that expresses the same intermediate result as a VIEW, a CTE and a TEMP TABLE and diffs the answers: 64 bugs found, 63 confirmed, 54 previously unknown logic bugs across MySQL, MariaDB, Percona and OceanBase. The technique ports to Postgres's CTE/view/temp-table paths essentially unchanged. (Niu, Chen, Chen, Xie · Aug 31) [paper]
  • Decoupling disaggregated-memory optimizations from indexing — "Nox" rewrites an unmodified concurrent index's LLVM IR to expose allocation and pointer-dependency information, then auto-generates RDMA/CXL versions of B+-trees, hash tables and skip lists that match or beat hand-tuned disaggregated indexes. (Zhao, Long, Wongkham, Srivastava, Lo, Liu, Lu, Wang · CUHK/Purdue/MSR/SFU, Sep 2) [paper]
  • Reducing the cross-model tax: query optimization over multi-model data — shows most of the overhead in decomposition-based federated querying is the unifying planner's fault, not heterogeneity: model-aware predicate pushdown plus cross-model dependent joins over PostgreSQL/MongoDB/Neo4j cut latency by two orders of magnitude and remove the OOM failures of the naive plan. (Bártík, Štrobl, Holubová · Sep 4) [paper]
  • ByteX: a unified AI search engine at ByteDance — production numbers from ~7,000 clusters and 300 PB, including a near-trillion-vector deployment: symmetric quantization lets graph-index construction run entirely in quantized space, with no full-precision copy and 80% less build memory. (Tian, Lu, Xiong, Xu et al. · ByteDance, Aug 31) [paper]

International (non-English sources)

  • pgsql-hackers watch, August 2026: an LLM triage of bug reports puts PG 19 features on the chopping block — the Japanese monthly -hackers column, and the best outside summary of the trend this digest opens with: Robert Haas clustered recent bug reports with an LLM and surfaced that the FK-check speedup, REPACK/REPACK CONCURRENTLY, online checksum enablement and SQL/PGQ are all drawing heavy report volume, prompting revert discussions — with hackers openly wondering whether AI is simply finding bugs faster than before. Also covers the seven SSI bugs Andrey Borodin consolidated, and a recovery-pipelining patch that splits WAL decoding into its own process for a reported 20–42% speedup. (Yugo Nagata · SRA OSS, Sep 4) [ja] (orig: 「pgsql-hackersウォッチ(2026年8月)」)
  • PG 19 temporal tables measured: 36% off updates, 76% once you add the row locks it needs — pgbench against 19beta3: read throughput 100:68 and update 100:64 for plain transparent temporal tables, falling to 100:32 once you add the SELECT ... FOR UPDATE row locks the docs now say READ COMMITTED requires, and 100:24 with a retry loop. With foreign keys in play, both the locking and retry variants collapse below 1 TPS and still deadlock regularly. The author's verdict: too expensive for a contended OLTP database. (harukat1232000 · Qiita, Sep 6) [ja] (orig: 「PostgreSQL19でテンポラルテーブル設計の新時代へ(3)」)
  • ora2pg silently drops every Oracle procedure carrying AUTHID — and 19 other quiet mistranslations — feeding ora2pg 25.0 a procedure with AUTHID CURRENT_USER emits only -- Nothing found of type PROCEDURE, exit code 0, no warning; utPLSQL alone has AUTHID in roughly 50 package specs. Also: TO_DATE('85-06-01','RR-MM-DD') passes through unchanged and returns 0001-06-01 BC on PG 16 with no error, and the naive RR→YY rewrite is wrong because Postgres pivots at 69/70 while Oracle's RR pivots at 49/50. (Lunch418 · Habr, Aug 31) [ru] (orig: «ora2pg молча выбросил процедуру целиком, и это не самое обидное»)
  • 2.5 TB of 1C data, no backups, pg_resetwal — and every backend spinning in _btmoveright — admins deleted WAL files on a live server, kill -9'd the postmaster, then ran pg_resetwal; the server started and every non-trivial query hung. The signal-40 stack dump showed backends stuck in _btmoveright — corrupted system catalog btrees, not user indexes. Recovery ran through ignore_system_indexes, then a patched pg_dump, because --data-only still calls pg_get_indexdef() over every OID. (Postgres Professional · Habr, Sep 4) [ru] (orig: «Если ваш админ — самурай, или История восстановления очень нужных данных»)
  • Chaos-testing a built-in HA cluster: 8–11 s to declare a node dead, 20 s to promote — five deliberate failure modes (clean stop, kill -9, node reset, network cut, hung process) produced the same reaction curve every time; the interesting spread is on the application side, where recovery ranged from 20 s to "never reconnects" depending purely on client timeouts. Observable behaviour only — SQL views, logs, stopwatch — with the author explicitly disclaiming any involvement with the feature's own team. (Alexey Lesovsky · Habr, Sep 1) [ru] (orig: «Postgres Pro BiHA на практике: аварийное тестирование встроенной отказоустойчивости»)
  • Huge Pages and shared_buffers: the pairing that quietly eats hundreds of GB, or refuses to start — huge pages cover shared memory only, never work_mem sorts or hash tables; the reservation is physically pinned, so 400 GB reserved with huge_pages = off is 400 GB gone for good. shared_memory_size_in_huge_pages is the number to hand Linux (1 GB is 260k 4 KB pages against 512 2 MB pages), and huge_pages = on against an undersized pool means the instance simply does not come up. (SOFTPOINT · Habr, Sep 4) [ru] (orig: «Записки оптимизатора 1С (ч.19). Как настройка Huge Pages в Linux влияет на устойчивость работы Postgres»)
  • Three TiDB tuning post-mortems: stale stats, a partition-pruning trap, and AUTO_INCREMENT write hotspots — an 800M-row table where SHOW STATS_HEALTHY returned 25 against a pass mark of 80, so a composite index degenerated into scanning 100,000 rows to return 20 (40 s → 180 ms after ANALYZE); log_time > NOW() - INTERVAL 3 DAY showing partition:all because the optimiser won't prune on a non-constant expression (30 partitions → 3, 12 s → 350 ms with a literal); and AUTO_INCREMENT on a clustered PK putting 100x the write traffic on the last Region, fixed with AUTO_RANDOM(6). (Marvelyu · tidb.net, Sep 4) [zh] (orig: «TiDB SQL 调优实战:从"跑不动"到"飞起来"的三个真实案例»)
  • Schema archaeology: LinuxFr ran without a single foreign key until 29 arrived in one commit — an MIT-licensed tool that renders a Postgres/MySQL/SQLite dump (or a pgModeler/DBML/Prisma schema) as one self-contained static HTML ER diagram, no runtime and no DB connection. The good part is the author's own run over LinuxFr's schema.rb history: 53 structural states from 2010 to 2026, with tables floating unrelated for years because FK constraints lived only in Rails models until 29 landed together on 24 March 2018. (Patu · LinuxFr, Sep 1) [fr] (orig: «MCDView : un schéma SQL en diagramme entité-association interactif, en un fichier HTML statique»)
  • Verified quiet this window: blog.vonng.com [zh] — newest post Aug 29, two days before the window; blog.dalibo.com [fr] — newest post Aug 18. Cybertec's German blog is gone: /de/ now redirects to /en/ and both /de/postgresql-blog-de/ and /de/category/blog-de/ 404, so [de] had no native-language DBMS write-up at all this week.

Call for papers

Upcoming events

New sources added this week

  • tapoueh.org (Dimitri Fontaine) — long-form, everything-verified-against-a-build Postgres writing; this week's PG 19 piece was the strongest item in the digest. P2.
  • richyen.com (Richard Yen) — infrequent but original: catalog archaeology, version-portability tooling, no product attached. P3.
  • SRA OSS tech blog — pgsql-hackers watch (Yugo Nagata) [ja] — a monthly -hackers digest written by a Postgres contributor; the single most useful non-English source for tracking upstream discussion. P2.
  • tidb.net [zh] — the TiDB community blog; heavily PR-padded, but the tuning post-mortems and index deep-dives are real. Mine, don't subscribe. P3.
  • Community: r/vectordatabase, r/mariadb (the MariaDB Foundation posts its newsletter and community polls there) and r/DuckDB added to the weekly sweep.
  • Retired: dev.mysql.com/blog-archive is dead (last post 2025-03-06; the page itself now redirects readers to blogs.oracle.com/mysql), and Cybertec's German blog no longer exists.

58 items · yield — mailing lists: 796 messages in window (588 hackers / 58 bugs / 6 general / 0 performance / 150 committers) → 34 shortlisted → 28 published · blogs: 61 posts in window → 29 shortlisted → 22 published · community: ~549 threads viewed → 22 shortlisted → 4 published · research: 37 cs.DB preprints in window → 16 shortlisted → 7 published · international: ru 11→5→4, ja 37→5→2, zh 13→3→1, fr 2→1→1.

Source notes: pgsql-hackers, -bugs, -performance and -general were enumerated through postgresql.org/list/<name>/since/<ts>/ in the browser pane — four since/ fetches covered all seven days with no gaps this run. pgsql-committers came from mail-archive's thread index (msg48669–48819); its date index was not needed. Cross-origin fetch() from the pane is CORS-blocked, so blog bodies were read through search-seeded plain fetches instead. CommitFest: the open CF rolled from PG20-2 (#61) to PG20-3 (#62) during the window, so both were captured; the ~100-row activity-log cap again lost Aug 31 and Sep 1 morning on both, and the queue totals are the trustworthy delta. Hacker News was scanned in full via the Algolia API (keyword sweep plus a query-less pass above 8 points) and genuinely had nothing — that is a finding, not a gap. Not reached this run: modb.pro [zh] (still a client-rendered shell with no dated article list, even in a real browser), postgrespro.ru/blog (client-rendered list returned no entries), and cnblogs' full-text search (human-verification challenge). publickey1.jp, cn.pingcap.com, oceanbase.com and developer.aliyun.com yielded no datable in-window listing and should be treated as unchecked rather than quiet. One in-window Planet PostgreSQL post carried a June byline on its own site and was dropped as out-of-window rather than published.