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

  1. In walreceiver, don't try to do ereport() in a signal handler.