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>, Robert Haas <robertmhaas@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-19T02:57:45Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> Interesting, but I'm not sure how that could be though.  Perhaps, a
> bit like the other thing that cropped up in the build farm after that
> commit, removing ~200ms of needless sleeping around an earlier online
> CHECKPOINT made some other pre-existing race condition more likely to
> go wrong.

The data that we've got is entirely consistent with the idea that
there's a timing-sensitive bug that gets made more or less likely
to trigger by "unrelated" changes in test cases or server code.

			regards, tom lane



Commits

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