Re: Race conditions with checkpointer and shutdown
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-29T15:23:13Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Sun, Apr 28, 2019 at 12:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Even if that isn't the proximate cause of the current reports, it's >> clearly trouble waiting to happen, and we should get rid of it. > +1 > That reminds me, we should probably also clean up at least the > ereport-from-signal-handler hazard identified over in this thread: > https://www.postgresql.org/message-id/CAEepm%3D10MtmKeDc1WxBM0PQM9OgtNy%2BRCeWqz40pZRRS3PNo5Q%40mail.gmail.com Yeah, probably. I imagine the reason we've not already seen complaints about that is that not that many custom bgworkers exist. I do not think we can get away with back-patching a change in that area, though, since it'll move the goalposts about what bgworker code has to do to cope with SIGTERMs. It might already be too late for v12, unless we want to treat that as an Open Item. regards, tom lane
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