Re: Can a child process detect postmaster death when in pg_usleep?
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Stephen Frost <sfrost@snowman.net>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-07-06T10:24:07Z
Lists: pgsql-hackers
Attachments
- v2-0001-Use-a-WaitLatch-for-Pre-and-Post-Auth-Delay.patch (application/octet-stream) patch v2-0001
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.
Commits
-
Use WaitLatch() instead of pg_usleep() at the end of backups
- 2aca19f2989a 15.0 landed
-
Use WaitLatch() instead of pg_usleep() at end-of-vacuum truncation
- 70685385d70f 15.0 landed
-
Use a WaitLatch for vacuum/autovacuum sleeping
- 4753ef37e0ed 14.0 cited
-
Revert "Get rid of the dedicated latch for signaling the startup process".
- 00f690a23993 14.0 cited