PostgreSQL 19 delayed to 19 November: what was reverted, what AI review had to do with it, and what to test in RC 1

PostgreSQL 19 will not ship in September as major releases usually do. The first release candidate came out on 15 October, a second is planned for 12 November, and general availability is now set for 19 November 2026 (PostgreSQL RC 1 announcement). On the way there the project pulled several headline features, including SQL/PGQ property graphs, UPDATE/DELETE ... FOR PORTION OF and online data checksums, after a late wave of post-commit review. Some of that review was done with AI tools, which is why the story is now being told as "AI reviewers found more bugs than humans can fix".

This article sets out what was actually reverted and why, what the committers themselves say about AI's part in it, and what is left in 19 for you to test. It ends with the SQL checks worth running against your own clusters before you try RC 1, because several of the changes that did stay will break an upgrade or change query behaviour quietly.

The new PostgreSQL 19 release dates

On 10 October Jonathan Katz of the release team told pgsql-hackers that RC 1 stays on 15 October, a new RC 2 lands on 12 November alongside the scheduled minor releases, and GA moves to 19 November. His reason: a large number of fixes had piled up in the back branches and the team wanted testers to get them in an RC before GA. He called it "an atypical major release cycle". The RC 1 announcement repeats the date with the usual hedge: GA happens on 19 November "unless an issue is discovered that requires a delay or an additional release candidate" (PostgreSQL).

Dates are from the PostgreSQL 19 open items page and the RC 1 announcement. Christophe Pettus notes that as recently as 12 October the GA target was 29 October, itself already a slip from the usual late-September date (The Build).

What was reverted from PostgreSQL 19

Tomas Vondra went through every revert of the cycle in a post on 1 October and judged, one by one, whether AI-found bugs caused it. His list has twelve entries. Some are whole features, some are parts of one:

Two of those matter most if you were planning around 19. SQL/PGQ (GRAPH_TABLE queries over property graphs) and MERGE/SPLIT PARTITION are now described as version 20 material (Snowflake). And REPACK CONCURRENTLY stays, but its prerequisite, database-specific logical replication snapshots, was reverted, so in 19 only one REPACK (CONCURRENTLY) can run at a time across the whole cluster (Robert Haas).

GROUP BY ALL went for a reason worth knowing about if you were waiting for it: post-commit review found it mishandled ORDER BY entries with non-default equality semantics and returned wrong results (Snowflake).

How a Claude ranking started the September reverts

On 25 August Robert Haas opened a thread on pgsql-hackers called "scary patch contest". He had asked Claude to rank the version 19 patches by how alarming they were, judged by the number and type of bugs fixed after feature freeze, and he asked whether any should be reverted before release. Six patches made his list:

The fixes were not trivial. Haas's list includes an out-of-bounds write and incorrect foreign-key enforcement in the RI fast path, data loss and broken TOAST handling in REPACK, and three security fixes in FOR PORTION OF, where inserts bypassed INSERT row-level security policies and WITH CHECK OPTION was not enforced on DELETE (Haas). For checksums he pointed out that false positives are a bad failure mode for a feature whose job is detecting corruption. Within three weeks, three of the six were reverted outright and the RI fast path lost its batching; REPACK and the postgres_fdw statistics import stayed, and RC 1 ships further fixes for both (The Build, RC 1).

Did AI reviewers cause the PostgreSQL 19 delay?

The committers closest to it say mostly not. Vondra's verdicts give one revert to AI, one possibly AI and ten to ordinary human review or design problems. His conclusion: "I would not rate any of the AI findings as 'critical' or 'unfixable before release'" and the reverts were "simply a consequence of there being too many post-commit issues" (Vondra). His summary paragraph says four of the twelve came out as AI or probably AI, which does not match his own table; the per-revert verdicts are the ones to trust.

The opposing view came from inside the thread too. Melanie Plageman suggested that LLMs make it easy to pressure-test features, so bugs surface sooner than they used to, and Bruce Momjian asked the list whether 19 had needed an unusual number of cleanup patches for that reason (Momjian). Daniel Gustafsson's answer turns the question around: most large features in 19 were "written, reviewed and tested, before AI tools were either available or even remotely as good as they are now", and he expects feature freeze for 20 to look different (Gustafsson).

Pettus puts it most bluntly: "Review did not increase. Review happened late." He notes that reverts usually cluster around day 300 after feature freeze; for 19 the line stayed flat and then spiked in early September (The Build). Where AI does seem to have changed the workload is security. Vondra: "Last year we had maybe 5 CVEs, this year we're already at 44", and the August update for 18 alone carried 28 (Vondra, Snowflake). Every hour a senior committer spends on a security report is an hour not spent reviewing new features.

What still ships in PostgreSQL 19

Plenty. The release notes list REPACK (and REPACK (CONCURRENTLY), which does not block reads and writes), the pg_plan_advice extension for steering planner decisions with pg_stash_advice to apply advice per query, automatic scaling of I/O worker processes, faster foreign-key checks, logical replication that can be switched on without a restart when wal_level is replica, logical replication of sequence values, a WAIT command for read-your-writes on standbys, and parallel autovacuum of indexes. Snowflake's list adds ON CONFLICT DO SELECT and IGNORE NULLS in window functions (Snowflake).

Six open items were still listed when we checked the open items page, among them "CHECK constraint enforced only by the child is not enforced on some paths" and "Promotion and standby replay hang behind a backend blocked on a stuck client". If either touches your setup, watch those before you plan the move.

Upgrade changes that will bite

These come from the "Migration to Version 19" section of the release notes. Most are quiet: nothing fails, behaviour just changes.

• JIT is off by default. If you run large analytical queries and rely on JIT, turn it back on with jit = on and measure.
• max_locks_per_transaction defaults to 128 instead of 64, and the notes say an explicit setting has to be doubled to keep the capacity you had before. Check any value you set by hand.
• standard_conforming_strings is always on. Dumps taken with pre-19 pg_dump from a server where it was off will not load correctly; dump again with 19's tools.
• pg_upgrade refuses clusters with database, role or tablespace names containing carriage returns or line feeds, and clusters with btree_gist indexes on inet or cidr, whose opclasses could skip rows that should be returned.
• RADIUS authentication is removed, as are the MULE_INTERNAL encoding and the escape_string_warning setting.
• MD5 password logins now log a warning after success (md5_password_warnings), and a new password_expiration_warning_threshold defaults to seven days.
• json_array() over no rows returns [], not NULL. Any COALESCE or IS NULL check around it changes meaning.
• postgres_fdw passes READ ONLY and DEFERRABLE through to remote sessions, so a read-only local transaction can no longer write through a foreign table.

Check your cluster before you try RC 1

Run these against each production cluster now, on 18 or earlier. Each returns rows only where something needs attention. The pg_authid query needs a superuser.

-- 1. btree_gist indexes on inet/cidr: pg_upgrade to 19 refuses theseSELECT n.nspname AS schema, ic.relname AS index_name, opc.opcnameFROM pg_index iJOIN pg_class ic     ON ic.oid = i.indexrelidJOIN pg_namespace n  ON n.oid = ic.relnamespaceJOIN pg_opclass opc  ON opc.oid = ANY (i.indclass::oid[])WHERE opc.opcname IN ('gist_inet_ops', 'gist_cidr_ops'); -- 2. Names containing CR or LF: pg_upgrade to 19 refuses theseSELECT 'database' AS kind, datname AS name FROM pg_database WHERE datname ~ '[\r\n]'UNION ALLSELECT 'role', rolname FROM pg_roles WHERE rolname ~ '[\r\n]'UNION ALLSELECT 'tablespace', spcname FROM pg_tablespace WHERE spcname ~ '[\r\n]'; -- 3. RADIUS lines in pg_hba.conf: the method is gone in 19SELECT line_number, type, database, user_name, auth_methodFROM pg_hba_file_rulesWHERE auth_method = 'radius'; -- 4. Roles still on MD5 passwords: they will log warnings in 19SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%'; -- 5. Settings whose defaults or meaning change in 19SELECT name, setting, boot_val, sourceFROM pg_settingsWHERE name IN ('jit', 'max_locks_per_transaction', 'standard_conforming_strings');

Then test the binary upgrade itself on a copy. pg_upgrade --check runs the compatibility checks without touching data; the RC 1 announcement says moving to 19 needs pg_upgrade or pg_dump/pg_restore, like any major version (RC 1). Paths below are Debian/Ubuntu-style; adjust for your packaging.

# Run as the postgres user, with both 18 and 19 RC 1 binaries installed/usr/lib/postgresql/19/bin/pg_upgrade \  --old-datadir=/var/lib/postgresql/18/main \  --new-datadir=/var/lib/postgresql/19/main \  --old-bindir=/usr/lib/postgresql/18/bin \  --new-bindir=/usr/lib/postgresql/19/bin \  --check