← All digests

DBMS Weekly — 2026-09-28 (week of Sep 28–Oct 4)

PostgreSQL 19 now has dates: RC1 on 15 October and GA on 29 October. The week before was spent removing risk. RI fast-path batching was taken out of master as well as 19, and REPACK (CONCURRENTLY)'s last two open items (lost TOAST updates, leftover dropped-column data) were committed. Three back-patched fixes closed silent failures on the stable branches: a logical-replication subscriber skipping changes during concurrent index DDL, slot invalidation clobbering another backend's flags so that VACUUM could remove rows a standby still needed, and PG18 self-join elimination dropping RLS quals. Last week's initial-snapshot hint-bit bug produced its first field report: FK violations after failover that verify_heapam() cannot see. The other storyline is where the reverts and the bug flood come from. Tomas Vondra traced all twelve PG19 reverts and found only four plausibly driven by AI-found bugs; his explanation is a CVE wave eating reviewer time. MariaDB reported the same surge in security reports, and the poolers took the hits (Pgpool-II shipped seven CVEs a week after PgBouncer's three). The CommitFest queue nearly quadrupled to 433 active entries as PG20-2 closed with 116 commits, its best September since 2015.

PostgreSQL

  • Are we reverting patches because of bugs found by AI? — a committer goes through all 12 PG19 reverts and traces each one to the review that killed it. Only 4 are "AI" or "possibly AI": CREATE SCHEMA object types (found by an LLM review), plus partial credit on RI fast-path batching. SQL/PGQ, FOR PORTION OF, MERGE/SPLIT PARTITIONS and the pg_get_*_ddl() functions all went out on human reviews. Charts of revert counts per development day from PG14 to 19 show similar totals but different timing: earlier releases reverted right after feature freeze (about day 300), while PG19 stayed flat until about day 430. His explanation is reviewer time, with 44 CVEs this year against about 5 last year, many of them AI-reported. (Tomas Vondra · vondra.me) [by committer]
  • The Linux kernel from a PostgreSQL point of view — LWN's write-up of Andres Freund's Kernel Recipes talk (slides). He says direct I/O will "probably never be the default". (Jonathan Corbet · lwn.net) His kernel wishlist:
    • scalability dips that disappear when cpuidle is disabled
    • futexes: 32 bits of state is too little, and kernel hash lookups cost up to 25% of CPU
    • overcommit_memory=2 doesn't work inside cgroups
    • fallocate() reservations fragment files and cost journal writes
    • 1 GB huge pages contend on the folio head and can halve throughput
    • buffered RWF_ATOMIC would let WAL shrink
  • A Hint of Dependence — a member of the SQL standard committee argues that plan hints belong next to the query, not inside it. He starts from Codd 1970 (an IDS program that named its index chains broke when the chains were removed), then surveys SQL Server, MySQL and Oracle hint syntax. In Oracle a misspelled hint is silently ignored, and two of the three manuals advise against using hints at all. The Postgres history follows: the 1999 refusal, the 2011 Haas/Lane/Grittner thread, OFFSET 0 as an undocumented fence, and PG12's MATERIALIZED as the first documented hint. He ends on why pg_plan_advice/pg_stash_advice, which keep plan control outside the SQL text, are the right shape. (Vik Fearing · thegresqlpost.org)
  • All your GUCs in a row: max_wal_size and min_wal_size — a checkpoint is triggered at max_wal_size/(1+checkpoint_completion_target), which on 14+ defaults is 33 segments (528 MB), and that threshold has moved twice across versions with no GUC change. On 18.6 pgbench, 1 GB against 8 GB meant 3,815 vs 1,080 MB of WAL and 447,963 vs 91,335 FPIs, at about 10% fewer TPS. min_wal_size keeps nothing a standby can read; it only puts a floor under recycled files. Nothing ever creates files to reach that floor, so a promoted standby starts with about 160 MB of pool whatever the setting. (Christophe Pettus · thebuild.com)
  • min_parallel_*_scan_size and max_worker_processes — the scan minimum is also the bottom rung of the planner's tripling ladder for worker counts. Setting it to 0 gave a 9.6 MB table 7 workers, and the query took 33–37 ms against 10 ms serially. Of the 8 worker slots, the logical replication launcher takes one even on a standby. When the slots run out, the failures differ: on 19beta4 REPACK (CONCURRENTLY) fails outright with "out of background worker slots", parallel queries quietly run with fewer workers, and a pg_cron job fails after waiting 10 s. (Christophe Pettus · thebuild.com)
  • Nobody patches the pooler — a follow-up to PgBouncer 1.26's three CVEs. auth_type=md5 gives no protection, because SCRAM secrets in pg_authid upgrade the login to SCRAM. The hang CVE is worse than the crash, since nothing restarts a pinned core. The interim fix is max_packet_size below 1 GB plus a firewall, and 1.26 also removes -R online restart. (Christophe Pettus · thebuild.com)
  • Pgpool-II 4.7.3 / 4.6.8 / 4.5.13 / 4.4.18 / 4.3.21 — security release with 7 CVEs. (Pgpool Global Development Group · postgresql.org)
    • 5 are in watchdog message handling: an arbitrary 32-bit write, overflows, a NULL dereference, and an auth-key bypass that can promote any node to leader
    • CVE-2026-92868: a NUL byte in a client certificate's CN lets a client log in as another user without a password
    • a heartbeat-receiver information leak
  • Why ClickHouse Managed Postgres uses direct I/O for backups — measured on an i8ge.12xlarge with a 467 GB database. A buffered wal-g base backup evicted a whole warm 40 GiB table from the page cache; O_DIRECT cut the query-latency hit by about two thirds with about 14% less CPU. The catch: wal-g's default 128 KiB direct reads land on a single drive of a RAID0 with 512 KiB chunks. Once the read size spanned the stripe (4 MiB), the backup took 71 s. (Kaushik Iska · clickhouse.com) [vendor blog — substantive]
  • Memory safety for Postgres extensions in C/C++ — PG_TRY's longjmp skipping C++ destructors is undefined behaviour, not just a leak. Four extensions show four ways around it. (Philip Dubé · clickhouse.com) [vendor blog — substantive]
    • pg_clickhouse removed C++ entirely and got a new C client
    • pg_re2 keeps C++ behind try/catch and never calls back into Postgres
    • pg_chdb moved libchdb out to a fork+exec helper, so a crash fails the call without triggering crash recovery
    • pg_stat_ch routes std::terminate to ereport(FATAL), which the authors flag as a mitigation, not a guarantee
  • Row-level security performance, measured and PgBouncer and RLS — PG17.10, 2M rows. (Chris van Eijk · now-next.nl)
    • a VOLATILE plpgsql policy helper turned every query into a ~1.9 s seq scan
    • an inlinable SQL helper stopped inlining once it had SECURITY DEFINER or SET search_path (3.8–4.6 s)
    • an IN (SELECT … memberships) policy cost about 80 ms per query
    • non-leakproof lower()/LIKE took the largest tenant's lookup from 0.2 ms to 34–45 ms
    • behind PgBouncer in transaction mode, SET LOCAL outside a transaction does nothing; combined with an earlier client's SET, one session read another tenant's 267,023 rows
  • Job queues per tenant: the noisy neighbour — round-robin SKIP LOCKED cut small tenants' median wait from 4.5 s to 0.10–0.15 s. With a skewed backlog, though, the natural ORDER BY id subselect walked 100k jobs per idle tenant (9,960 ms per dequeue). A partial (tenant_id, enqueued_at, id) index plus ordering by enqueued_at brought that to 1.17 ms. (Chris van Eijk · now-next.nl)
  • PlanetScale released text search and we have a lot to say (part I) — ParadeDB's reply to TIN. (Ming Ying · paradedb.com) [vendor blog — substantive] [unverified: vendor-run QPS against a closed competitor]
    • BM25 fieldnorms stored in an array indexed by DocId turned 83% of page accesses into scattered reads; storing them next to each postings list took one query from about 1,500 pages to 30
    • a Lucene-style MAXSCORE path for disjunctions of 3 or more terms gave about 6× at p50
    • TIN's "dense-term elision" only approximates BM25, and the StackExchange benchmark's queries were built from consecutive word spans like "is it"
  • Designing Neki for performance — a sharding router that keeps PostgreSQL DataRow/Bind frames as raw bytes. It decodes nothing for a point lookup and finds only row boundaries for LIMIT. For a cross-shard merge it decodes and caches only the sort key, and it drops a hidden ORDER BY column by copying runs of column frames. Vitess, by contrast, converts every row at each RPC boundary. (Dirkjan Bussink · planetscale.com) [vendor blog — substantive]
  • DocumentDB 0.117: scalar $group index pushdown and 0.116: $sort/$group prefix pushdown — how Microsoft's MongoDB-API extension lowers aggregation pipelines onto Postgres plans. A scalar $sum is answered from the index with no hint, behind a GUC that is off by default, and a sort-then-group pipeline streams in index order with no blocking sort. Buffers and heap fetches are compared against MongoDB 8.0. (Franck Pachot · dev.to)
  • OrioleDB public beta, Multigres alpha — OrioleDB is now a per-table option (USING orioledb next to heap), with an undo log instead of VACUUM and 64-bit XIDs. It claims "up to 1.8× heap" on a TPC-C-derived benchmark. Multigres, from the Vitess team, adds consensus over synchronous replication and is in private alpha. (Supabase · supabase.com) [vendor blog] [unverified: 1.8× is self-benchmarked]

PostgreSQL mailing lists

  • [hackers] PostgreSQL 19 RC1 and GA release dates — RC1 is set for Thursday 15 October and GA for Thursday 29 October, if the RC period turns up nothing significant. That puts GA two weeks ahead of the November minor releases. In the same week, BUG #19742 reported a new PG19-only planner regression: INTERSECT ALL under a UNION ALL whose other arm is WHERE false fails with "could not find pathkey item to sort" on 19beta4 and works on 18.6. Tom Lane bisected it to fdda78e361. Last week's 50× dblink NOTICE slowdown was fixed in master and 19 on 28 Sep. (Jonathan S. Katz; Junwen AN / Tom Lane; vignesh C · pgsql-hackers) [open]
  • [hackers] Revert RI fast-path batching from REL_19_STABLE — after the 10 Sep revert from 19, Amit Langote removed batching from master too on 3 Oct. His reason: new cases kept turning up where holding FK checks back to fill a batch changes their result, most recently other AFTER ROW triggers modifying the referenced table before a buffered check ran. The per-row fast path, which probes the PK index without SPI, stays in 19. Batching, or at least its relation and slot caching, may come back as a separate proposal. (Amit Langote; Robert Haas, Melanie Plageman, Amit Kapila · pgsql-hackers) [committed]
  • [hackers] REPACK (CONCURRENTLY) might keep dropped-column data — rows changed during the run by anything other than a plain UPDATE keep their dropped-column values: a subscriber's apply, or a BEFORE UPDATE trigger that does RETURN OLD. In one test the table went 2,424 kB → 224 kB with plain REPACK, but ended at 2,616 kB with CONCURRENTLY under updates. Herrera's fix nulls dropped attributes as changes are applied and was pushed on 3 Oct. Last week's TOAST lost-update open item is also closed: the TOAST table is now locked early in cluster_rel(), committed 28 Sep. (Radim Marek / Álvaro Herrera / Antonin Houska; TOAST fix by Shihao Zhong · pgsql-hackers) [committed]
  • [hackers] amcheck: detect corruption from the recent snapshot-export bug — the first field report tied to last week's initial-snapshot hint-bit bug: FK violations after failover. The cause was tuples marked HEAP_XMIN_INVALID whose xmin is committed in pg_xact; pg_visibility found them on the standby, but verify_heapam() did not. Patch 0001 makes verify_heapam() report this state and should be back-patched alongside the fix; 0002 adds wider hint-bit cross-checks. How to repair data that is already damaged is still open. (Andrey Borodin · pgsql-hackers) [patch posted]
  • [committers] Fix tuple search during apply after concurrent index DDL — the apply worker decided twice whether its lookup index was the replica identity or PK, while holding only RowExclusiveLock. A DROP/REINDEX INDEX CONCURRENTLY between the two checks could flip the answer to "compare whole rows", so the search found nothing, logged update_missing, and skipped the change. The subscriber then silently diverged. Back-patched to 16. A follow-up on 2 Oct applies the same rule to the sequential deleted-tuple search. (Mihail Nikalayeu, vignesh C; reviewed by Amit Kapila, Zhijie Hou · pgsql-committers) [committed]
  • [committers] Fix clobbering of proc entry's statusFlags during slot invalidation — when the checkpointer or startup process invalidated a slot, ReplicationSlotRelease() wrote statusFlags at pgxactoff. That field is 0 for auxiliary processes, so the write landed on another backend's flags. Losing PROC_AFFECTS_ALL_HORIZONS lets VACUUM remove rows a standby still needs, even with hot_standby_feedback on. Back-patched to 14. (Vlad Lesin; reviewed by Hayato Kuroda, Michael Paquier · pgsql-committers) [committed]
  • [committers] Prevent self-join elimination when RTEs' checkAsUser fields differ — in PG18, SJE could merge two references to the same table that carry different security quals, and drop RLS quals that must be enforced. It traces back to 2ebf25e7d, which started regenerating baserestrictinfo from securityQuals after SJE. The fix merges only RTEs with the same checkAsUser, which is cheaper than comparing qual trees. Back-patched to 18. (Tom Lane; reported by Yonghwa Lee · pgsql-committers) [committed]
  • [hackers] Corruption Issue: Fix missing tts_tid in ExecForceStoreHeapTuple — tuples coming out of the index-scan reorder queue (KNN GiST with a lossy distance recheck) lose their ctid. Under FOR UPDATE, the invalid TID's block number equals P_NEW, so heap_lock_tuple() extends the table with an uninitialized page before erroring, and later seqscans fail with "invalid page in block N". All supported branches are affected. Andres Freund found a second visible symptom (INSERT … RETURNING ctid returning a wrong TID) and wants tts_tid set on every path. v8 is CF #7371. (Virender Singla, Greg Burd / Andres Freund · pgsql-hackers) [patch posted]
  • [bugs] Wrong results: hashed SubPlan referenced twice after OR-qual extraction reuses a stale hash table — reproduced from 13.23 through 18.6 and 19beta4, with default settings. After OR-qual extraction, the same hashed SubPlan appears in both a scan filter and a join filter. Each copy has its own hash table, but they share one PlanState, so one copy rebuilds on a parameter change while the other probes a stale table. An access-check EXISTS returns false for a row where it should be true; OFFSET 0 is a workaround. (Samuel Olaoye / Rahul Yadav, CF #7384 · pgsql-bugs) [patch posted]
  • [bugs] Backend crash in pg_trgm makesign() after ALTER TABLE … SET STORAGE on a gist_trgm_ops column — SET STORAGE EXTENDED/MAIN copies the column's attstorage onto the index column, although the opclass stores PLAIN gtrgm. Later inserts then write short varlena headers that the TRGM macros misread, and the next INSERT or non-HOT UPDATE segfaults. REINDEX crashes the same way. Reproduced on 16.15–18.6 and first seen on Aurora and RDS. Kirill Reshke notes that btree, hash and BRIN are protected; any opclass whose STORAGE type differs from its input type is exposed. (Thiago Bonfante / Andrey Rachitskiy, Kirill Reshke · pgsql-bugs) [patch posted]
  • [hackers] BUG #19686: Rolling back SET TABLESPACE — ALTER TABLE … SET TABLESPACE copies the heap to a new relfilenode but leaves the indexes in place. Later inserts in the same transaction update the indexes in place but the heap only in the copy, so a ROLLBACK leaves index and heap out of step. Freund and Lane rejected deferring the copy to COMMIT (Tom: putting likely-to-fail work into COMMIT is "an anti-pattern"). The consensus is to give the indexes a new relfilenode whenever the heap moves. v2 does that and also fixes SET TABLESPACE; TRUNCATE; ROLLBACK, which empties the index on master. (Alexandre Felipe / Andres Freund / Tom Lane / Manu · pgsql-hackers) [patch posted]
  • [hackers] ATTACH PARTITION cost grows linearly with pg_constraint size (PG 18) — CloneFkReferenced() has always seqscanned pg_constraint on confrelid, which stayed cheap until 18 moved NOT NULL constraints into the catalog. Measured at 1M pg_constraint rows: 0.07 → 20.7 ms per ATTACH on 18.6, flat on 17.11. The fix adds a catalog index on confrelid (CF #7365), master-only. A side proposal for partial indexes on catalogs was rejected as "just a hack". (Bernhard Wonisch / Manu / Álvaro Herrera · pgsql-hackers) [patch posted]
  • [hackers] Measuring fix pace and disclosed AI involvement across PG 12–18 — no replies yet, but it puts numbers on Vondra's post above. The August 2026 minors had 142 release-note items, against 63–78 per scheduled release in 2025. CVEs per release went from 2–3 to 14 in May and 29 in August. 26 stable-branch fix commits disclose AI involvement, all since April, and 22 of them credit an AI tool with finding the bug. New -hackers/-bugs threads disclosing AI rose from under 1% to about 8%, while total list traffic stayed flat. (Josh Andrews · pgsql-hackers) [unverified: author's own analysis]

CommitFest (open: PG20-3, #62)

  • Balance (Sep 28 – Oct 4): 41 new · 16 closed (7 committed / 6 withdrawn / 2 rejected / 1 returned with feedback) → net +25. (vs last week's ≥ +15, about +10. This week's counts are complete, not lower bounds: new entries were counted from the sequential patch IDs #7353–#7393, and closures from each patch's own history.) 10 entries moved to Ready for Committer.
  • PG20-2 closed on 1 Oct with 539 entries and 116 committed, the most for a September CF since 2015. 140 active entries moved across automatically and 195 stayed behind, including 31 Ready for Committer. After Álvaro Herrera warned that stale bug fixes were dropping out of sight, 58 Bugfix entries were carried into PG20-3. PG20-3 starts 1 Nov and has no manager yet. Queue at scan: 303 needs review · 37 waiting on author · 93 ready for committer (433 active, up from 119).
  • New this week: UNDO with constant time recovery (CTR) (Greg Burd) — a generic UNDO subsystem that leaves heap alone. It can log UNDO records into the shared WAL or into per-backend UNDO logs, as zheap did. The first user is transactional filesystem operations (create/mkdir/rename), so a crash no longer leaves orphaned files. nbtree/hash UNDO sits behind an index_undo reloption, and a prototype table AM ("FLUX") is included. The first review found that a crash during CREATE DATABASE still leaves the directory behind, and that plain filesystem errors can now crash the server. Also new: Protocol Compression (fourth attempt) (#7361), Let an ordering index scan hand its ORDER BY value to the target list (#7392), Skip LEFT/ANTI joins to a provably empty inner rel (#7360), Planning time quadratic in the IN-list length with BitmapOr (#7393), Reduce LWLockWaitListLock() cache-line contention (#7376), GROUP BY ALL (#7378, resubmitted after its PG19 revert), standby PANIC on restart after VM truncation (#7386), Fix pg_trgm GiST union dropping SIGNKEY (#7385, already Ready for Committer).
  • Closed: committed: Fire create_upper_paths_hook for UPPERREL_PARTIAL_GROUP_AGG (#7140), Report index currently being vacuumed in pg_stat_progress_vacuum (#7095), BUG: pg_class.relchecks overflow (#7343), Reset waitStart when a lock wait fails (#7341), Set calcSumX2 = true in numeric deserialize (#7334), Two remaining shmem attachment issues in single-user mode (#7320), small cleanup for s_lock.h (#6734). Rejected: Restore idempotency of pg_enable_data_checksums() (#7070), intXshr/intXshl: error on out-of-range shift (#7367). Returned with feedback: Reduce WAL volume for heap tuple hint bits (#7118). Withdrawn: six entries, among them pg_rewind does not rewind diverging timelines (#7317).

Community pulse

  • turbopuffer drops the vector-primary index, and HN reads it as Postgres vs InnoDB again — the post explains that turbopuffer stored every document under its ANN cluster address, so each SPFresh rebalance rewrote the document and every index pointing at it. v3 makes ANN an ordinary secondary index; a turbopuffer engineer confirmed the new primary key is an internal (segment ID, doc ID). Commenters recognised InnoDB's trade-off (secondary indexes point at the PK, at the price of an extra lookup) and brought up Uber's 2016 Postgres write-amplification post. malisper pushed back on the popular reading: PK-addressed secondary indexes are what make undo logging possible, and undo removes the need for vacuum. Most agreed the title is marketing, and that "RIP, vector-primary index" would have been accurate. (Hacker News · 394 pts, 116 comments)
  • Supabase buys Turso, and the thread asks why anyone rewrote SQLite — the most upvoted question was why you would rewrite "one of the best tested pieces of software in the world". The answers: async I/O, concurrent writers and an open contributor model, plus the fact that SQLite's full test suite is private. The technical sub-thread was about ClickBench loading stalling for a year, which Turso's co-founder answered by pointing to Turso 0.8's concurrent writes (below). (Hacker News · 218 pts, 117 comments)
  • An LLM on read-only Postgres decided status_cd = 4 meant "cancelled"; it meant "refunded" — a Postgres MCP server on a read-only role gave analysts a lost-orders number off by about a third, because the code meanings lived only in an application enum. Replies agreed the fault was in the schema, not the model. The suggested fixes were a lookup table or a real Postgres enum, COMMENT ON COLUMN as a stopgap, or a semantic layer before any agent touches source tables. A parallel r/dataengineering thread on why text-to-SQL keeps failing (75 comments) landed in the same place. (r/SQL · 33 pts, 72 comments)
  • Raw SQL vs query builders, again — started from FunSQL's essay on "SQL-structured" vs "data-oriented" builders. The top comment argued that pipe syntax answers most of the criticism. The raw-SQL camp kept queries static with WHERE $1 IS NULL OR foo = $1 and col = ANY($1); someone asked whether planners actually handle that pattern well, and nobody answered. Where it landed: builders that mirror SQL clauses add little, while pipeline builders (FunSQL, PRQL) earn their keep through composability, but "you still have to know the SQL it maps to". (Lobsters · 39 pts, 32 comments)
  • Tigris moved async tasks off its FoundationDB queue — Tigris built Apple's QuiCK design on FoundationDB, then moved GC-style tasks to Kafka once scheduling scans started competing with user reads. The most upvoted pushback: this shows FoundationDB was a bad fit, not that databases are. A table queue is fine at modest volume and close to essential as a transactional outbox; its weak spot is ordering guarantees, which are "remarkably difficult" to get from Postgres. (Lobsters · 13 pts, 22 comments)

Wider DBMS & distributed data

  • Join ordering, part 1: the shape of the search space — the first of a six-part walk through the Munich join-enumeration line: DPccp (VLDB'06), DPhyp (SIGMOD'08), adaptive optimisation of very large joins (SIGMOD'18), and Birler & Neumann's CD-E conflict detection (DBPL'25), which is complete and efficient for non-inner joins. Part 1 covers tree shapes, the (2(n−1))!/(n−1)! count of join trees, and why DP over relation sets works, with Rust code. (deferworks.org)
  • Foreign key constraints in Aurora DSQL — FKs without Postgres's FOR KEY SHARE blocking. DSQL validates against a snapshot at statement time and settles conflicts at commit under OCC. It tracks an implicit KEY SHARE, so only updates to key columns conflict. Constraints are added with ALTER TABLE ASYNC … VALIDATE CONSTRAINT, and cascades are bounded by the per-transaction row limit. (Rekha Reddy Anupati, Arnab Chowdhury · AWS Database Blog) [vendor blog — substantive]
  • Turso 0.8: concurrent writes — the Rust rewrite of SQLite. (Pekka Enberg · turso.tech)
    • BEGIN CONCURRENT MVCC plus group commit: p99.9 commit latency of 2.4 ms at 32 connections, against 1.2 s for SQLite, whose busy-wait backoff accounts for most of its tail
    • 9,497 vs 1,375 TPS at 64 connections, on disjoint keys, so a best case
    • SQLite is still faster with a single connection
  • Valkey memory, version by version — 1M SETs with 16-byte values, built from source with jemalloc 5.3.0. Bytes per key went from 102.48 (7.2) to 64.02 (9.1), −37.5%. The biggest step is 8.1's 64-byte cache-line bucket hashtable with key and value embedded (−23.8%). Smaller ones are 8.0's key-in-dictEntry (−7.8%) and 9.1's short strings stored inside the pointer field (−11.1%). (Percona · percona.com)
  • DuckDB 1.5.6 — a bug-fix release, with v2.0.0 due in October. (DuckDB team · duckdb.org)
    • correctness: LIMIT pushdown through a volatile projection with OFFSET; filter pushdown on volatile groups; wrong results from common-subplan elimination across UNION ALL arms; NULLs in Top-N window elimination
    • recovery: failed-checkpoint marker recovery; WAL handle closed before rename; ART dead-node counting

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

  • The FETCH FIRST story: ROW_NUMBER() in 12c, back to ROWNUM in 23ai — Oracle implemented FETCH FIRST as a rewrite to analytic ROW_NUMBER(), which lost first-K-row costing until 19c's fix control 22174392 (WINDOW NOSORT STOPKEY). In 23.4, fix control 35915968 rewrites the simple case back to ROWNUM/COUNT STOPKEY. Using DBMS_UTILITY.EXPAND_SQL_TEXT and the 10053 trace, he shows the analytic path returning wrong results with an outer-joined lateral view. (Franck Pachot · dev.to)
  • When AI finds the bugs we missed — MariaDB used to get at most 16 security reports a quarter; this year it got 81, then 92, nearly all valid. The project now publishes its own advisories instead of waiting for CVE assignment, and admits that triage delayed releases. The pattern showed on the tracker the same weekend: one reporter filed six optimizer wrong-result bugs in a single night (e.g. MDEV-41380: BIGINT/DECIMAL vs DOUBLE comparisons return different rows with and without an index). (Frédéric Descamps · mariadb.org)
  • From SELECT to SYSADMIN with SQL Copilot (CVE-2026-65669) — Copilot in SSMS runs with the connected user's privileges, and its "read-only mode" was a system-prompt instruction plus a regex blocklist. DECLARE @p sysname='sp_who'; EXEC @p got past it, which made this a critical elevation of privilege. A design lesson for any agent-facing database tool. (Johann Rehberger · embracethered.com)
  • When pt-online-schema-change --where meets Galera — with a selective --where whose matching rows sit at the end of the PK, the adaptive chunk sizer sees fast, nearly empty chunks and keeps growing them. By the time it reaches the matching rows, it copies hundreds of thousands of rows per transaction. That triggered Galera flow control on every node, and the production cluster stayed locked for dozens of minutes until restart. The first fix is to turn off adaptive resizing. (Corrado Pandiani · percona.com)

Migration experience

  • Upgrading a 56 TB database growing 250 GB/day with (nearly) no downtime — to get past an Aurora 14.15→14.22 minor that needed a reboot, they moved only the 1.23 TB control plane plus all new runs to another provider and routed by run-ID format. (Daniel Sutton · trigger.dev)
    • pgcopydb's CDC stalled for 15 h at 0 MB/s because libpq kept memmoving a 512 MB buffer; their patch flushes every 1 MB (2.71 s → 0.74 s per 100k-statement transaction)
    • the first cutover failed after 105 s of errors: PgBouncer keys pools by (db, user), so connections already open kept the old username
    • the rollback then hit cache lookup failed for type, because clients had cached the other cluster's type OIDs
  • BigQuery to ClickHouse at 15M call-minutes a day — rebuilding a Postgres CDC pipeline. (Vikram · bolna.ai) [unverified: cost figure is the author's]
    • Datastream MERGEs scanned an unpartitioned table, and data arrived 5–15 minutes late
    • after the move to ClickPipes/PeerDB, FINAL on ReplacingMergeTree caused memory spikes, so they switched to refreshable materialized views
    • unchanged TOASTed JSONB never arrived until they set REPLICA IDENTITY FULL
    • what actually cut CDC volume was writing only the final call state instead of every status change (about 6× cheaper overall)

Research & cutting edge

  • KNDB: a PostgreSQL 18 table access method that resolves conflicts at write time — rows are ordinary heap tuples, typed MEASURED/INFERRED/DERIVED. It overrides 7 of the 44 TAM callbacks (insert, multi_insert, update, delete, both speculative-insert callbacks, relation_toast_am), delegates the other 37 to heap, and gives a completeness argument over the interface. Most useful as a worked example of a "mostly-heap" TAM; the truth-discovery results are mixed. (Maguluri, Kommuri, Sinha, Sood) [paper]
  • Fixing the Fixpoint: convergence detection for incremental recursive computation — shows that DBSP's commonly suggested "FirstZero" fixpoint test is unsound even in natural cases, and that exact fixpoint detection is impossible for arbitrary DBSP circuits. It gives a sound internal-convergence detector that is complete for Datalog and nested-while queries and their incremental versions, verified in Lean. Relevant to IVM over recursive CTEs. (Yang, Chajed, Reps) [paper]
  • HakiCC: LLM agents design application-specific concurrency control — a multi-agent system writes a CC protocol for a workload and repairs it until it verifies conflict-serializable, then an evolutionary loop tunes its throughput. All 10 generated protocols (TPC-C, AuctionMark) were serializable, and tuning raised throughput by +50.6% (TPC-C) and +92.2% (AuctionMark) on average over the first versions. (Habibi, Fang, Nawab) [paper]
  • VADER: filtered vector search with declarative recall — the user states a target recall instead of tuning ef/probe parameters. A filter-aware recall predictor, which generalises across predicate selectivity and filter–vector correlation, stops the search once the target is predicted to be met. Up to 53% faster and 28% better in quality than the best baseline. (Chatzakis, Lu, Caminal, Chronis, Özcan, Papakonstantinou et al. · VLDB 2027) [paper]
  • JEVDB: prune first, decide fast for semantic SQL — evaluates semantic filters and joins with typed decision models instead of autoregressive LLMs, escalating only uncertain cases. Semantic joins are first cut down with Yannakakis-style semijoin reduction and "Semantic Bloom Filters". It had the lowest latency on all 21 SemBench queries. On the TPC-DS-derived Shelob, the filters remove 87.4% of candidate pairs before evaluation and escalations fall 55.2%. (Wang, Yan, Zhao, Liu) [paper]
  • Temporal Trace Graphs: automatic prefetching across dependent DB round trips — a per-request graph of candidate objects, built from statically extracted access and continuation rules, drives an async prefetcher while application code walks an object graph stored in PostgreSQL. Up to 2.99× end-to-end in three of four apps. The authors report that planning overhead can exceed the latency it saves. (Li, Dantanarayana, Kashmira, Tang, Mars) [paper]
  • Ditto: reconfigurable linearizable reads — maps fast linearizable-read algorithms into one design space with a latency model. It finds two trade-offs, read vs write latency and read vs write tolerance to network variance, and adds Pairwise Quorums plus runtime switching between algorithms. The abstract gives no numbers. (Panas) [paper]
  • Separating adaptive, normal, linear, entropic and submodular width — one explicit 32-vertex graph whose five width measures are pairwise distinct. Theory behind which width governs worst-case-optimal join evaluation. (Lanzinger, Merkl, Suciu) [paper]

International (non-English sources)

  • Greenplum as an extension of PostgreSQL 19: Cloudberry on 22 core hooks — a personal experiment: Apache Cloudberry ported onto stock PG 19 as extensions, in 12 days and 629 commits, mostly written by LLM agents. It needed only 22 new core extension points (about 1.5K lines), and the list reads as a map of what PG lacks for MPP: an OID-allocation hook, combo-CID hooks, XactAdoptTransactionState() so reader slices can join a writer's transaction, a parser hook, smgr file events, a table-AM registry. With the extension not loaded the server behaves as vanilla: the same 371 meson tests pass, and abidiff shows 0 changed symbols. ORCA beat the gather route by a 3.1× geomean on TPC-H SF1. Only 691 of 1,180 Cloudberry test files run so far. (igor_suhorukov · Habr) [ru] (orig: Greenplum как расширение PostgreSQL 19)
  • Aurora PostgreSQL's DuckDB integration, measured — aurora_analytics 1.0.0 on Aurora PG 18.6, TPC-H SF10. Cold rows went to S3/Iceberg behind UNION ALL views, cutting storage from 14.50 to 1.80 GiB. A naive SELECT * view silently changed results: imported columns come back as text with C collation, so char(n) padding vanished and ORDER BY changed (EXPLAIN shows "Unsupported Pushdown Expressions: Collation"). With types and collations aligned, results match at 1.4–2.5× the original time. A point lookup went from 0.164 ms to 0.70 s, because rows are returned to PG before aggregation. (asahide · Qiita) [ja] (orig: Aurora PostgreSQL の DuckDB 統合を試してみた)
  • CloudNativePG: OOM kill and pod QoS — Kubernetes QoS sets the postmaster's oom_score_adj to 1000 for BestEffort/Burstable and −997 for Guaranteed, and CNPG sets PG_OOM_ADJUST_VALUE=0 only for Guaranteed pods. A work_mem='1000GB' sort hit a global OOM at about 8 GB in the first two classes and a memcg OOM at the 2 GiB limit in the third. In every case memory.oom.group killed the whole cgroup, postmaster included, followed by crash recovery. So with overcommit left on, one backend's OOM still restarts the instance whatever the QoS. (Pierrick Chovelon · Dalibo) [fr] (orig: Plongez dans le monde de CloudNativePG #13 - OOM Kill et QoS)
  • Beyond EXPLAIN: watching a query run live across an MPP cluster — pg_query_state ported to Apache Cloudberry, by the person who did the port. The coordinator gathers (segid, pid) pairs and dispatches an SQL function to every segment, which signals its local backends, because signals can't cross hosts. Per-host Go agents pre-aggregate plan-node stats, so the coordinator never has to merge thousands of per-process trees. Not yet production-tested. (Alexey Rozhok · Yandex Cloud on Habr) [ru] (orig: За пределами EXPLAIN: как увидеть выполнение запроса вживую в распределённой СУБД)
  • SQL Server uses CHECK constraints to turn NOT IN into point seeks — on a production query, adding CHECK (State IN (0..10)) let the optimizer rewrite State NOT IN (0,6,8) as IN (1,2,3,4,5,7,9,10). Four open-ended B-tree ranges became point seeks: rows read fell from 659,796 to 114,496 and logical reads from 11,268 to 2,301, with no new index. PG uses CHECK constraints only for constraint_exclusion and partition pruning. (SKB Kontur on Habr) [ru] (orig: О пользе ограничений в MSSQL)

Upcoming events

  • PG Down Under 2026 — Sydney, 30 October — the sixth ANZ community conference; the program is published. Internals picks:
    • Delta Frame of Reference Compression (Evgeny Voropaev) — delta/bit-packed integer compression already wired into WAL prune/freeze records (over 5× on offset arrays), with GIN TID lists next.
    • An OpenTelemetry API for PostgreSQL and its extensions (Craig Ringer) — pluggable tracing and metrics on unpatched PG 18+, traced through FDWs and synchronous replication; optional core patches add protocol-level trace context. Offered explicitly as a core-design proposal.
    • Reparsing Postgres (James Sadler) — a standalone PG-dialect parser checked against PG's regression suite: where the grammar stops being LALR(1), and how to do name resolution and type inference on top.

New sources added this week

  • thegresqlpost.org — SQL-standard and relational-theory essays with real Postgres history, from a member of the standard committee. (Vik Fearing)
  • deferworks.org — query optimisation worked through from the papers (join enumeration, query compilation), with code.
  • paradedb.com/blog — search-in-Postgres internals (postings layout in Postgres pages, MAXSCORE/WAND); vendor, judge each post.
  • lwn.net — edited coverage of Postgres–kernel work and community process; subscriber links surface on HN.
  • duckdb.org — engine-team posts and release notes with real fix lists.
  • qiita.com/asahide — measured AWS-database write-ups with version, ACU and data size stated. [ja]

58 items · yield — mailing lists: 785 messages in window (652 hackers / 112 bugs / 0 performance / 21 general, plus 137 pgsql-committers) → 46 shortlisted → 21 published · blogs: ~115 posts in window → 82 shortlisted → 31 published · community: ~165 threads viewed → 27 shortlisted → 7 published · research: 46 cs.DB preprints announced in window → 19 shortlisted → 8 published · international: ru 16→10→3, zh 7→2→0, ja 40→5→1, fr 2→1→1, de 2→2→0 (polyglot search unavailable this run; native-language web search, feeds and browser used instead).