Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>,
"Anton A. Melnikov" <aamelnikov@inbox.ru>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2023-07-25T01:36:03Z
Lists: pgsql-hackers
On Tue, Jul 25, 2023 at 8:18 AM Robert Haas <robertmhaas@gmail.com> wrote: > (Yeah, I know we have code to verify checksums during a base > backup, but as discussed elsewhere, it doesn't work.) BTW the the code you are referring to there seems to think 4KB page-halves are atomic; not sure if that's imagining page-level locking in ancient Linux (?), or imagining default setvbuf() buffer size observed with some specific implementation of fread(), or confusing power-failure-sector-based atomicity with concurrent access atomicity, or something else, but for the record what we actually see in this scenario on ext4 is the old/new page contents mashed together on much smaller boundaries (maybe cache lines), caused by duelling concurrent memcpy() to/from, independent of any buffer/page-level implementation details we might have been thinking of with that code. Makes me wonder if it's even technically sound to examine the LSN. > It's also why we > have to force full-page write on during a backup. But the whole thing > is nasty because you can't really verify anything about the backup you > just took. It may be full of gibberish blocks but don't worry because, > if all goes well, recovery will fix it. But you won't really know > whether recovery actually does fix it. You just kind of have to cross > your fingers and hope. Well, not without also scanning the WAL for FPIs, anyway... And conceptually, that's why I think we probably want an 'FPI' of the control file somewhere.
Commits
-
Try to handle torn reads of pg_control in frontend.
- 63a582222c6b 17.0 landed
- 43c979086825 12.17 landed
- 67060be3df34 13.13 landed
- dc75748a918e 14.10 landed
- 5e39884d322a 15.5 landed
- 5725e4ebe7a9 16.1 landed
-
Acquire ControlFileLock in relevant SQL functions.
- f1634c968101 11.22 landed
- 637e86ecc5e4 12.17 landed
- ae9da357bd6d 13.13 landed
- a56fe5cf07fe 14.10 landed
- 606be8a35d97 15.5 landed
- 2371432cd6b9 16.1 landed
- c558e6fd92ff 17.0 landed