Re: Can a child process detect postmaster death when in pg_usleep?

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Can a child process detect postmaster death when in pg_usleep?
Date: 2021-07-06 00:45:08
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2021-07-06 01:02:28 Re: Evaluate expression at planning time for two more cases
Previous Message David Rowley 2021-07-06 00:40:02 Re: Minor typo in generate_useful_gather_paths comment