Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"
David Steele <david@pgmasters.net>
From: David Steele <david@pgmasters.net>
To: Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>, Stephen Frost
<sfrost@snowman.net>, 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-10-14T15:42:23Z
Lists: pgsql-hackers
On 10/13/23 10:40, David Steele wrote: > On 10/12/23 19:15, Michael Paquier wrote: >> On Thu, Oct 12, 2023 at 10:41:39AM -0400, David Steele wrote: >>> After some more thought, I think we could massage the "pg_control in >>> backup_label" method into something that could be back patched, with >>> more >>> advanced features (e.g. error on backup_label and pg_control both >>> present on >>> initial cluster start) saved for HEAD. >> >> I doubt that anything changed in this area would be in the >> backpatchable zone, particularly as it would involve protocol changes >> within the replication commands, so I'd recommend to focus on HEAD. > > I can't see why there would be any protocol changes, but perhaps I am > missing something? > > One thing that does have to change, however, is the ordering of > backup_label in the base tar file. Right now it is at the beginning but > we need it to be at the end like pg_control is now. Well, no protocol changes, but overall this does not seem like a direction that would be even remotely back patch-able. See [1] for details. For back branches that puts us back to committing some form of 0001 and 0003. I'm still worried about the performance implications of 0001 on a standby when in backup mode, but I don't have any better ideas. If we do commit 0001 and 0003 to the back branches I'd still like to hold off on HEAD to see if we can do something better there. Regards, -David [1] https://www.postgresql.org/message-id/e05f20f9-6f91-9a70-efab-9a2ae472e65d%40pgmasters.net
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