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

From: David Steele <david(at)pgmasters(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Daniel Gustafsson <daniel(at)yesql(dot)se>, "Anton A(dot) Melnikov" <aamelnikov(at)inbox(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"
Date: 2023-10-13 14:40:44
Message-ID: 88c6f15c-31b8-9c46-d0ae-f5cabc61be5b@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2023-10-13 14:44:13 Re: LLVM 16 (opaque pointers)
Previous Message Dmitry Dolgov 2023-10-13 13:35:19 Re: pg_stat_statements and "IN" conditions