Re: Race conditions with checkpointer and shutdown
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-17T23:39:16Z
Lists: pgsql-hackers
On Wed, Apr 17, 2019 at 10:45 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > I think what we need to look for is reasons why (1) the postmaster > never sends SIGUSR2 to the checkpointer, or (2) the checkpointer's > main loop doesn't get to noticing shutdown_requested. > > A rather scary point for (2) is that said main loop seems to be > assuming that MyLatch a/k/a MyProc->procLatch is not used for any > other purposes in the checkpointer process. If there were something, > like say a condition variable wait, that would reset MyLatch at any > time during a checkpoint, then we could very easily go to sleep at the > bottom of the loop and not notice that there's a pending shutdown request. Agreed on the non-composability of that coding, but if there actually is anything in that loop that can reach ResetLatch(), it's well hidden... -- Thomas Munro https://enterprisedb.com
Commits
-
In walreceiver, don't try to do ereport() in a signal handler.
- ac8f2e1ef34f 10.9 landed
- 9346d396fd4a 11.4 landed
- a1a789eb5ac8 12.0 landed