Re: Can a child process detect postmaster death when in pg_usleep? - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Can a child process detect postmaster death when in pg_usleep?
Date
Msg-id CALj2ACVF8AZi1bK8oH-Qoz3tYVpqFuzxcDRPdF-3p5BvF6GTxA@mail.gmail.com
Whole thread Raw
In response to Re: Can a child process detect postmaster death when in pg_usleep?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Can a child process detect postmaster death when in pg_usleep?  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Tue, Jul 6, 2021 at 1:38 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Jul 06, 2021 at 12:42:21PM +0530, Bharath Rupireddy wrote:
> > I'm sorry to say that I didn't get what was said above. We reset the
> > latch after we come out of WaitLatch but not before going to wait. And
> > the reason to have WL_LATCH_SET, is to exit the wait loop if MyLatch
> > is set for that process because of other SetLatch events. Am I missing
> > something here?
>
> Did you test the patch with post_auth_delay and a backend connection,
> making sure that the delay gets correctly applied?  I did, and that
> was not working here.

Thanks. You are right. The issue is due to the MyLatch being set by
SwitchToSharedLatch before WaitLatch. If we use (WL_TIMEOUT |
WL_EXIT_ON_PM_DEATH), then the backends will honour the
post_auth_delay as well as detect the postmaster death. Since we are
not using WL_LATCH_SET, I removed ResetLatch. Also, added some
comments around why we are not using WL_LATCH_SET.

For PreAuthDelay, there's no problem to use WL_LATCH_SET as MyLatch
still points to the local latch(which is not set) in
BackendInitialize().

PSA v2 patch.

Regards,
Bharath Rupireddy.

Attachment

pgsql-hackers by date:

Previous
From: Alexey Lesovsky
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Bharath Rupireddy
Date:
Subject: Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options