Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

On 7/12/21, 9:00 AM, "Bharath Rupireddy" <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> As suggested in [1], starting a new thread for discussing $subject
> separately. {pre, post}_auth_delay waiting logic currently uses
> pg_usleep which can't detect postmaster death. So, there are chances
> that some of the backends still stay in the system even when a
> postmaster crashes (for whatever reasons it may be). Please have a
> look at the attached patch that does $subject. I pulled out some of
> the comments from the other thread related to the $subject, [2], [3],
> [4], [5].

+ <row>
+ <entry><literal>PostAuthDelay</literal></entry>
+ <entry>Waiting on connection startup after authentication to allow attach
+ from a debugger.</entry>
+ </row>
+ <row>
+ <entry><literal>PreAuthDelay</literal></entry>
+ <entry>Waiting on connection startup before authentication to allow
+ attach from a debugger.</entry>
+ </row>

I would suggest changing "attach from a debugger" to "attaching with a
debugger."

if (PreAuthDelay > 0)
- pg_usleep(PreAuthDelay * 1000000L);
+ {
+ /*
+ * Do not use WL_LATCH_SET during backend initialization because the
+ * MyLatch may point to shared latch later.
+ */
+ (void) WaitLatch(MyLatch,
+ WL_TIMEOUT | WL_EXIT_ON_PM_DEATH,
+ PreAuthDelay * 1000L,
+ WAIT_EVENT_PRE_AUTH_DELAY);
+ }

IIUC you want to use the same set of flags as PostAuthDelay for
PreAuthDelay, but the stated reason in this comment for leaving out
WL_LATCH_SET suggests otherwise. It's not clear to me why the latch
possibly pointing to a shared latch in the future is an issue. Should
this instead say that we leave out WL_LATCH_SET for consistency with
PostAuthDelay?

Nathan