PostgreSQL 19 on October 29: WAIT for Read-Your-Writes, REPACK Without the Lock, and What Got Pulled

PostgreSQL 19 Beta 4 shipped on September 24, 2026. Release candidate 1 is scheduled for October 15 and general availability for October 29, 2026, unless the RC period finds something significant. If you plan upgrades around the November minor releases, this GA lands two weeks before them, which is the usual timing.

What makes 19 worth a system-design note rather than an upgrade checklist is two features that change how you build on replicas and how you reclaim space, plus a Beta 4 that removed several features the earlier betas advertised. Read the second list before you quote the first.

WAIT: read-your-writes on a standby, in the database

A write goes to the primary. The next read goes to a replica that has not replayed it yet. The user sees their own save disappear. The application-level fixes are in read-your-writes after the primary: pin the next read to the primary, or carry a log position and route to a replica that has caught up.

PostgreSQL 19 adds the second option as a command. WAIT blocks on a standby until the standby has written, flushed, or replayed WAL up to a chosen LSN. The release notes name the pattern: it supports read-your-writes query patterns on standbys. The application captures the primary's LSN after the commit, sends it with the read, and the standby waits until it has replayed that far before running the query.

What this changes in a design: the replica can be the default read path even for the user who just wrote, as long as the write path returns the LSN and the read path passes it through. The wait is bounded by replication lag, and you still need a timeout and a fallback to the primary for a replica that is far behind. The Beta 4 notes mention fixes to a deadlock and clearer isolation-level error reporting in this command, so test it on the RC, not on your memory of Beta 1.

REPACK: VACUUM FULL and CLUSTER under one name, and a CONCURRENTLY option

VACUUM FULL rewrote a table to reclaim space. CLUSTER rewrote it in index order. Both took an access-exclusive lock for the duration, which is why they ran at 3 a.m. or not at all. PostgreSQL 19 adds REPACK, which does both jobs under one command. The old commands remain for compatibility.

REPACK ... CONCURRENTLY rebuilds the table without the access-exclusive lock, so reads and writes continue during the rebuild. That is the feature that moves bloat cleanup from a maintenance window to a background job. It also had a run of fixes in Beta 4 — crashes, incorrect behavior with invalid indexes and materialized views, permission and error-reporting corrections — which is normal for a new command touching storage, and a reason to run it on a copy before production.

Autovacuum gets workers and a scoring system

Autovacuum can use parallel workers to vacuum a table's indexes, controlled by autovacuum_max_parallel_workers and a per-table autovacuum_parallel_workers storage parameter. A new scoring system prioritizes which tables most need vacuuming or analyzing, replacing the simpler ordering. Beta 4 lists fixes to that scoring, including for TOAST tables.

For an operator this is a tuning change, not a behavior you can ignore. Tables that used to be vacuumed in a predictable order may be visited in a different one. Watch pg_stat_all_tables after the upgrade; it also gains a stats_reset column in 19.

Logical replication: sequences, and no restart to enable it

Logical replication now replicates sequence values, and publications can publish all sequences. CREATE SUBSCRIPTION, ALTER SUBSCRIPTION ... REFRESH PUBLICATION, and a new REFRESH SEQUENCES synchronize them; pg_get_sequence_data() exposes the state, and pg_stat_subscription_stats adds sync_seq_error_count. Separately, logical replication can be enabled without a server restart when wal_level is replica.

Sequence replication is the piece that makes a logical-replication failover less manual. The sequence on the subscriber no longer starts at a stale value after you promote it.

Planner advice, I/O workers, foreign keys

Two new modules, pg_plan_advice and pg_stash_advice, give you a way to stabilize and control planner decisions and to apply that advice automatically per query. That is the first first-party answer to "the plan changed after the upgrade and I need the old one back." The release also scales the number of I/O worker processes automatically and speeds up foreign-key constraint checks, which Beta 4 lists several fixes for.

What Beta 4 reverted

These were in Beta 1 and are not in 19:

• SQL/PGQ property graph queries.
• Online enabling and disabling of data checksums.
• FOR PORTION OF temporal updates and deletes.
• ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS.
• pg_get_role_ddl(), pg_get_tablespace_ddl(), and pg_get_database_ddl().

If a design document, a vendor roadmap, or a blog post from the spring promised graph queries or online checksums in 19, it is describing a beta. Plan for 20.

What to do before October 29

1. Install Beta 4, or RC1 on October 15, on a copy of production. Run REPACK CONCURRENTLY on your most bloated table and compare the lock profile to VACUUM FULL.
2. Prototype WAIT on a standby with a captured LSN from the primary. Measure how often the wait exceeds your read timeout under normal lag.
3. Set autovacuum_max_parallel_workers deliberately rather than inheriting the default, and watch which tables the new scoring picks first.
4. If you rely on logical replication for failover, test sequence synchronization and the no-restart enablement.
5. Strike the reverted features from any upgrade justification.

The release notes are the source of truth and still carry an "AS OF" date rather than a release date; they will be final at GA. The schedule is from the PostgreSQL release team's September 28 note to pgsql-hackers.