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

From Michael Paquier
Subject Re: Can a child process detect postmaster death when in pg_usleep?
Date
Msg-id YOOnlP4NtWVzfsyb@paquier.xyz
Whole thread Raw
In response to Re: Can a child process detect postmaster death when in pg_usleep?  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Can a child process detect postmaster death when in pg_usleep?  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
On Mon, Jul 05, 2021 at 09:42:29PM +0530, Bharath Rupireddy wrote:
> I agree. I'm attaching the patch that replaces pg_usleep with
> WaitLatch for {pre, post}_auth_delay. I'm also attaching Michael's
> latest patch stop-backup-latch-v2.patch, just for the sake of cfbot.

I don't object to the argument that switching to a latch for this code
path could be good for responsiveness, but switching it is less
attractive than the others as wait events are not available in
pg_stat_activity at authentication startup.  That's the case of normal
backends and WAL senders, not the case of autovacuum workers using
post_auth_delay if I read the code correctly.

Anyway, it is worth noting that the patch as proposed breaks
post_auth_delay.  MyLatch is set when reaching WaitLatch() for
post_auth_delay after loading the options, so the use of WL_LATCH_SET
is not right.  I think that this comes from SwitchToSharedLatch() in
InitProcess().  And it does not seem quite right to me to just blindly
reset the latch before doing the wait in this code path.  Perhaps we
could just use (WL_TIMEOUT | WL_EXIT_ON_PM_DEATH) to do the job.

The one for pg_stop_backup() has been applied, no objections to that.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Minor typo in generate_useful_gather_paths comment
Next
From: David Rowley
Date:
Subject: Re: Evaluate expression at planning time for two more cases