Re:Upgrading PostgreSQL with no data loss and minimal downtime
by pgelephant2025 on Friday November 28, 2025 @01:40PM
(#46081452)
Good write-up. I have a few questions.
How did you handle WAL slot growth while the logical replica stayed behind? A 3.5 TB database can produce large WAL backlogs during long sync windows.
Your throughput numbers look high. What storage and network setup produced 10 GB per minute for physical sync and 1 GB per minute for logical sync? Hardware details matter for planning.
Did you check extension state, custom types, sequences, and unlogged tables after the cutover? Logical replication skips many of those parts and they often break upgrades.
What was your rollback plan if the logical slot failed or the upgraded node drifted before cutover?
A short checklist for validation would help: row counts, sequence sync, extension checks, and any mismatch in default values.
How did you handle WAL slot growth while the logical replica stayed behind? A 3.5 TB database can produce large WAL backlogs during long sync windows.
Your throughput numbers look high. What storage and network setup produced 10 GB per minute for physical sync and 1 GB per minute for logical sync? Hardware details matter for planning.
Did you check extension state, custom types, sequences, and unlogged tables after the cutover? Logical replication skips many of those parts and they often break upgrades.
What was your rollback plan if the logical slot failed or the upgraded node drifted before cutover?
A short checklist for validation would help: row counts, sequence sync, extension checks, and any mismatch in default values.