Re: race condition when writing pg_control
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: "Bossart, Nathan" <bossartn@amazon.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-05-04T21:51:20Z
Lists: pgsql-hackers
On Tue, May 5, 2020 at 5:53 AM Bossart, Nathan <bossartn@amazon.com> wrote:
> I believe I've discovered a race condition between the startup and
> checkpointer processes that can cause a CRC mismatch in the pg_control
> file. If a cluster crashes at the right time, the following error
> appears when you attempt to restart it:
>
> FATAL: incorrect checksum in control file
>
> This appears to be caused by some code paths in xlog_redo() that
> update ControlFile without taking the ControlFileLock. The attached
> patch seems to be sufficient to prevent the CRC mismatch in the
> control file, but perhaps this is a symptom of a bigger problem with
> concurrent modifications of ControlFile->checkPointCopy.nextFullXid.
This does indeed look pretty dodgy. CreateRestartPoint() running in
the checkpointer does UpdateControlFile() to compute a checksum and
write it out, but xlog_redo() processing
XLOG_CHECKPOINT_{ONLINE,SHUTDOWN} modifies that data without
interlocking. It looks like the ancestors of that line were there
since 35af5422f64 (2006), but back then RecoveryRestartPoint() ran
UpdateControLFile() directly in the startup process (immediately after
that update), so no interlocking problem. Then in cdd46c76548 (2009),
RecoveryRestartPoint() was split up so that CreateRestartPoint() ran
in another process.
Commits
-
Fix locking bugs that could corrupt pg_control.
- 09dc17486393 9.5.23 landed
- 644cac32a0bc 9.6.19 landed
- fd11b842eba9 10.14 landed
- 48eb6a3c895d 11.9 landed
- 72766ad6397a 12.4 landed
- acefa2cca6a2 13.0 landed
- 57cb8063089a 14.0 landed