PostgreSQL 19 RC 1 went out on October 15, and the date that matters for anyone planning an upgrade is no longer “early October.” The PostgreSQL Global Development Group now plans general availability for November 19, 2026, with a second release candidate on November 12 — the same day as the next round of minor releases for supported branches.

For Houston teams running Postgres under a change calendar — trading and risk systems, pipeline historians, clinical platforms in the Texas Medical Center, port logistics — that slip is the story of this cycle. Here is what moved, and what to test now.

Why GA moved: the official reason is boring, and that is fine

The RC 1 announcement is explicit about the mechanism. The scheduled November 12 update release for supported versions “will include a large number of fixes,” and the release team decided those fixes should land in PostgreSQL 19 before it ships. RC 2 goes out the same day, and GA follows a week later — “unless an issue is discovered that requires a delay or an additional release candidate.”

Read that literally: the extra weeks are not for putting features back, but for folding accumulated fixes into the 19 branch. That kind of call gets cheaper the earlier your own rehearsal starts.

What is not in PostgreSQL 19

The bigger disruption came earlier: roughly eight to ten significant features, depending on how you count, were reverted after beta began — an unusually high number for a project that typically absorbs one. Among them:

• SQL/PGQ property graph queries, the standard syntax for querying node/edge relationships over relational tables.
• UPDATE/DELETE ... FOR PORTION OF, the temporal update syntax.
• Online enabling and disabling of data checksums.
• ALTER TABLE ... MERGE PARTITIONS / SPLIT PARTITIONS.
• pg_get_role_ddl(), pg_get_tablespace_ddl(), pg_get_database_ddl().
• GROUP BY ALL, database-specific replication snapshots, non-text pg_dumpall output, and the fast default for domains.

None of these return in a 19.x minor release: minor releases carry fixes, not features, so the earliest any can reappear is PostgreSQL 20. If a feature you needed is on that list, plan around its absence.

The AI-review story is messier than the headlines

Much of the coverage pinned the reverts on AI-assisted code review. It is a real factor but not the whole explanation.

Committer Peter Eisentraut, writing on October 9, listed several causes. Some features had architectural defects that could not be fixed safely during beta. On top of that came “a long tail of relatively harmless issues involving various edge cases” that would once have dribbled out as fixes over five years; LLM-assisted review surfaced them fast enough to leave reviewers “staring at a list of like forty defect reports” — each cheap alone, expensive in aggregate.

Committer Tomas Vondra then read the threads behind twelve reverts and asked which findings actually came from AI. His October 1 analysis rates only four as “probably AI” or “AI”; the rest trace to ordinary human review and design objections. He also points at what the headline misses: security work. With senior reviewers pulled into vulnerability handling — 44 CVEs logged this year against roughly five the year before, by his count — stabilization capacity dropped exactly when it was needed.

The practical read: a capacity story, not a “the database is unstable” story. RC 2 and the November minor releases are where the remaining risk sits.

What survived — and what to test first

The features that stayed are operational, and several target 24/7 systems that cannot afford long lock windows:

• REPACK CONCURRENTLY — returns bloat to the filesystem without the ACCESS EXCLUSIVE lock VACUUM FULL demands.
• pg_plan_advice and pg_stash_advice — control planner decisions per query and apply stored advice automatically, as an alternative to hint extensions.
• Logical replication of sequence values, plus enabling logical replication without a restart when wal_level is replica.
• WAIT FOR LSN — block until a standby has written, flushed, or replayed a WAL position, which turns read-your-writes across a replica pool into an explicit operation instead of a sleep.
• Parallel autovacuum of table indexes and autovacuum prioritization by a new scoring system.

-- Reclaim space on a hot table without blocking writes
REPACK (CONCURRENTLY, VERBOSE) meter_readings;

-- On a standby: block until this LSN has been replayed
WAIT FOR LSN '0/3A2B1C8'
  WITH (MODE 'standby_replay', TIMEOUT '30s', NO_THROW);

For the full rehearsal sequence, see PostgreSQL 19 RC 1: an ops plan to rehearse pg_upgrade now.

Four compatibility changes that will bite during pg_upgrade

Release notes matter less than the incompatibilities list when you are holding the pager. The ones most likely to stop a Houston estate cold:

• btree_gist indexes on inet/cidr. The default opclass for those types moves to GiST because the btree_gist versions can exclude rows that should be returned — and pg_upgrade refuses clusters that still have such indexes.
• max_locks_per_transaction default rises from 64 to 128, with a change in lock size allocation, so a carried-over setting no longer buys the same capacity.
• JIT is disabled by default. Cost-based JIT activation was judged unreliable; analytical workloads that quietly relied on it need it enabled deliberately.
• standard_conforming_strings is forced on, RADIUS authentication is removed, and carriage returns or line feeds in database, role, and tablespace names now block upgrades.

-- Pre-upgrade blocker: btree_gist inet/cidr indexes
SELECT c.relname AS table_name, ic.relname AS index_name
FROM pg_index i
JOIN pg_class c  ON c.oid = i.indrelid
JOIN pg_class ic ON ic.oid = i.indexrelid
JOIN pg_opclass op ON op.oid = i.indclass[0]
WHERE op.opcname IN ('inet_ops', 'cidr_ops')
  AND EXISTS (
    SELECT 1 FROM pg_depend d
    WHERE d.classid = 'pg_opclass'::regclass
      AND d.objid = op.oid
      AND d.refclassid = 'pg_extension'::regclass
      AND d.refobjid = (SELECT oid FROM pg_extension WHERE extname = 'btree_gist'));

SHOW max_locks_per_transaction;

Extensions moved with the major version

Two extension announcements landed alongside RC 1. pg_hint_plan 1.9.0 adds PostgreSQL 19 compatibility and path generation strategy support, with minor releases down the ladder — 1.8.1 for 18, 1.7.2 for 17, 1.6.3 for 16, 1.5.4 for 15, and 1.4.5 for 14. That last one is the final release planned for PostgreSQL 14 — a retirement item for anyone still running it.

pg_utl_smtp 2.0 adds asynchronous mode (pg_utl_smtp.asynchronous) and SSL/TLS connections, keeping the Oracle-style UTL_SMTP package for trigger-driven email — often the difference between a clean PL/SQL migration and rewriting every alerting procedure.

What to do before November 19

Run RC 1, then RC 2, in staging — not production. Release candidates are for finding your own incompatibilities, and a second RC on the schedule is the project telling you changes are still landing. Pin extension versions; a hint-plan upgrade mid-rehearsal invalidates the test. Rehearse pg_upgrade against a restored copy of the real cluster, including the btree_gist check above, and keep the November 12 minor release inside the same window.

Last week’s roundup still matters for the JDBC CVE patch and Citus query router changes: Postgres News: JDBC CVE Patch, Citus Query Routers.

If the November window is tight, our Postgres upgrade and performance consultants can review the cluster and the runbook with your team before the date is fixed.