On Thu, Oct 15, 2026 at 8:27 PM shihao zhong <[email protected]> wrote: > > Hi, > > Hayato, you are right, thanks. v4-0001 sets the latch again if a > barrier is still pending, as Manu suggested. With your change on top, > DROP DATABASE waited 60 seconds with v2-0001 and 15 ms with v4-0001. > > Manu, I took all of your test changes. On 19 and master the test fails > without 0001 and passes with it.
I agree that 0001 is what fixes the rest. I'm reviewing it now, but what I'm unsure about is whether to include it in v19 at this point. It creates a new place where barrier callbacks run in the middle of a protocol message, with any ERROR upgraded to FATAL, and every barrier type we add later will have to be safe there. Neither of the two types in v19 throws today, so this is more about what could break there later, but it's the kind of change I'd want more time on than RC gives us. >From the numbers upthread, a backend blocked writing to the client (for example COPY TO STDOUT, or taking a base backup) looks like the only case that is both likely and unbounded; the others either release themselves or can't happen on a standby. It also needs a consumer that has stopped rather than one that is just slow. There are workarounds in the meantime. Setting wal_level=logical on the standby skips the barrier entirely thanks to the recent commit. If it does happen, the startup process logs the holding PID every five seconds, and pg_terminate_backend() on that PID lets the promotion finish. So I'm currently leaning towards master only and we live with the restriction in v19. Feedback is very welcome. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
