Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep
Date
Msg-id 290F0AA5-DD3E-415A-B830-40FD4DCBD19D@amazon.com
Whole thread Raw
In response to Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep
List pgsql-hackers
On 7/12/21, 9:00 AM, "Bharath Rupireddy" <bharath.rupireddyforpostgres@gmail.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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Rename of triggers for partitioned tables
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Avoid repeated PQfnumber() in pg_dump