> So I'm currently leaning towards master only and we live with the > restriction in v19. Feedback is very welcome.
+1 to master only. I tried to break the three assumptions on current REL_19_STABLE (c705304a0f4, which has 239c4d30699), one fresh primary/standby pair per run, 97 runs, and they hold up: - Since 239c4d30699 the barrier wait only happens on a wal_level=replica standby that has a logical slot on it -- one created on the standby, or a failover slot synced by the slotsync worker (I measured both). Without such a slot a stuck COPY TO STDOUT or a stuck base backup no longer delays promotion (promoted 6/6, 10-27 ms). So the restriction is a bit narrower than it first looks. - With the slot, the only unbounded holders were backends blocked writing to a client that stopped reading: COPY TO STDOUT, a large SELECT, and a base backup (still waiting past 300 s). Idle, idle in transaction, CPU-bound queries, pg_sleep, advisory-lock and AccessExclusiveLock waits (including a lock the startup process itself holds), slow-but-alive readers at 256 KB/s, and cascading/logical walsenders all promoted in under 80 ms. A client stuck in authentication releases itself at authentication_timeout. - Both workarounds held: wal_level=logical on the standby promoted 19/19 in ~20 ms with the same stuck clients, and pg_terminate_backend() on the PID the startup process logs every 5 s finished the promotion in 9-73 ms in every hung run. One edge worth a footnote in the docs or release notes: if the stuck write is an ErrorResponse rather than a data message, pg_terminate_backend() does not release it, because PostgresMain sends the error with interrupts held (HOLD_INTERRUPTS before EmitErrorReport). That is not new in 19 and the trigger I used to reach it is contrived, but there the ways out are killing the client connection or tcp_user_timeout on the standby (10 s -> promoted in ~7 s); wal_level=logical avoids it too. Happy to share the scripts and the raw per-run numbers if they're useful. Regards, Manu
