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
-
In walreceiver, don't try to do ereport() in a signal handler.
- ac8f2e1ef34f 10.9 landed
- 9346d396fd4a 11.4 landed
- a1a789eb5ac8 12.0 landed