Re: Exit walsender before confirming remote flush in logical replication - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Exit walsender before confirming remote flush in logical replication
Date
Msg-id CAKAnmmJ1urVN1XaTe_prd1Gh-cJ9QKEQ1G3zwSmT6SYwJ-mKBw@mail.gmail.com
Whole thread
In response to Re: Exit walsender before confirming remote flush in logical replication  (Andrey Silitskiy <a.silitskiy@postgrespro.ru>)
Responses Re: Exit walsender before confirming remote flush in logical replication
List pgsql-hackers
On Fri, Mar 13, 2026 at 8:00 AM Andrey Silitskiy <a.silitskiy@postgrespro.ru> wrote:
Сhecking got_SIGUSR2 alone is not enough. If we received got_STOPPING, got_SIGUSR2 will be set only if WalSndCaughtUp is true. This may fail, and then the test hangs with the inability to terminate walsender.

Got it, thanks
 
 > Tests:
 > * Should test something other than -1 and 0 (e.g. a positive value)

I'm not sure if it's worth adding a test containing a long timeout wait. I can add a test-case with a small positive parameter value (for example, 200ms). However, I don't think it will be possible to verify the time period for which the walsender was actually terminated. Still, it will be limited to checking the fact of termination. What do you think?

+1. I don't think we need to measure any times, but we do need to exercise that whole part of the code, so even a setting of 5ms would be an improvement. Without it, the tests don't even touch the second half of WalSndCheckShutdownTimeOut(), which is really the interesting bit.

--
Cheers,
Greg


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: More speedups for tuple deformation
Next
From: Andrew Dunstan
Date:
Subject: Re: IS JSON predicate support for domain base type as JSON/JSONB/BYTEA/TEXT