Anyone who has cut over a database with logical replication knows the dance. The table data replicates beautifully, every row lands on the subscriber, and then you promote it to primary and the very first INSERT blows up with a primary key violation. The reason: the sequences backing your SERIAL and IDENTITY columns never moved. They sat at their initial values on the subscriber the whole time, so the new primary cheerfully tries to hand out an ID that already exists. For a feature that has been in Postgres since 10, this gap has cost a lot of people a lot of cutover-window stress.
Postgres 19 finally closes it with automatic sequence synchronization. The work landed across three commits from Amit Kapila:
-
96b37849 added publication support for sequences
-
f0b3573c introduced the
REFRESH SEQUENCEScommand -
5509055d implemented the synchronization worker.
Usage
Publications now take FOR ALL SEQUENCES:
-- Publisher
CREATE PUBLICATION upgrade_pub FOR ALL TABLES, ALL SEQUENCES;
-- Subscriber
CREATE SUBSCRIPTION upgrade_sub
CONNECTION 'host=publisher-db dbname=production'
PUBLICATION upgrade_pub;Behind the scenes, a new sequencesync worker pulls sequences over in batches. Each one tracks its state (INIT → READY) in pg_subscription_rel, same place table sync state already lives, so you can watch progress with a query you may already know:
SELECT srsubid, srrelid::regclass, srsubstate
FROM pg_subscription_rel
WHERE srsubstate IN ('i', 'r'); -- 'i' = INIT, 'r' = READYOne thing to keep in mind: sequences do not stay live the way table data does. They only sync when you explicitly run REFRESH SEQUENCES. So put this line in your cutover runbook, right before you promote, not after:
ALTER SUBSCRIPTION upgrade_sub REFRESH SEQUENCES;Closing Thoughts
Postgres has been chipping away at the logical replication gaps release by release. Postgres 18 picked up generated column support. Postgres 19 takes the bigger prize: sequence synchronization, which was easily the nastiest snag in zero-downtime upgrade and failover workflows.
The one big hole left is DDL replication. Schema migrations still need manual coordination, and there is no REFRESH SEQUENCES-equivalent waiting to rescue you. To be fair, that bothers me less than missing sequences did. When you promote a subscriber, you generally want the schema already in place and identical, so DDL replication matters mostly for steady-state replication, not cutover. Missing sequence values take down production the instant you flip over. Coordinating a DDL change, by contrast, is just standard operational hygiene. So I am happy to let DDL replication wait for a future release.