Horton

Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"

David Steele <david@pgmasters.net>

View thread View on postgr.es
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-13T14:40:44Z
Lists: pgsql-hackers 
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.

I'm working up a POC patch now and hope to have something today or 
tomorrow. I think it makes sense to at least have a look at an 
alternative solution before going forward.

Regards,
-David

Commits

  1. Try to handle torn reads of pg_control in frontend.

  2. Acquire ControlFileLock in relevant SQL functions.