Re: Lost walsender wakeup stalls synchronous commits until the standby's next reply (16+)

On Thu, Nov 12, 2026 at 9:42 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Tue, Nov 3, 2026 at 1:05 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > > WalSndWaitForWal() (logical) reads the flush pointer before WalSndWait() in the same way.
> >
> > Yes, so logical replication seems to have a similar issue.
> > I'll investigate that separately.
>
> Probably I was able to reproduce the same issue in logical replication
> by adding a sleep just before WalSndWaitForWal() calls WalSndWait().
>
> WalSndWaitForWal() checks the flush or replay position before
> WalSndWait() joins the waitlist. If the required WAL becomes available
> between these steps, the notification can be lost, leaving the sender
> asleep even though enough WAL is available to continue decoding.
>
> I've attached a patch that rechecks the position after joining the waitlist
> and skips the wait if enough WAL is available.

Thanks for the patch! v1 looks correct for WalSenderWaitForWal.

It seems that WaitForStandbyConfirmation (17+) has the same race: a
standby can confirm between NeedToWaitForStandbys() and joining
wal_confirm_rcv_cv. Later replies would not wake it until restart_lsn
advances, which could stall synchronous commits too.

The attached reproducer adds a 3s delay before joining the waitlist,
and resumes the standby during that delay. With wal_sender_timeout = 0
and pg_recvlogical -s 0, the sender stalls for about 10s, its idle
timeout, even if the standby has caught up.

If this is an issue, do we need to apply the recheck like
StandbySlotsHaveCaughtup() before registration as well?

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.