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>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: 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-12 14:41:39
Message-ID: d1c6a37f-a6ee-01d9-0955-150a9f7a6ee0@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/12/23 09:58, David Steele wrote:
>> On Thu, Oct 12, 2023 at 12:25:34PM +1300, Thomas Munro wrote:
>>> I'm planning to push 0002 (retries in frontend programs, which is
>>> where this thread began) and 0004 (add missing locks to SQL
>>> functions), including back-patches as far as 12, in a day or so.
>>>
>>> I'll abandon the others for now, since we're now thinking bigger[1]
>>> for backups, side stepping the problem.
>>
>> FWIW, 0003 looks like a low-risk improvement seen from here, so I'd be
>> OK to use it at least for now on HEAD before seeing where the other
>> discussions lead.  0004 would be OK if applied to v11, as well, but I
>> also agree that it is not a big deal to let this branch be as it is
>> now at this stage if you feel strongly this way.
>
> Agreed on 0002 and 0004, though I don't really think a back patch of
> 0004 to 11 is necessary. I'd feel differently if there was a single
> field report of this issue.
>
> I would prefer to hold off on applying 0003 to HEAD until we see how [1]
> pans out.
>
> Having said that, I have a hard time seeing [1] as being something we
> could back patch. The manipulation of backup_label is simple enough, but
> starting a cluster without pg_control is definitely going to change some
> things. Also, the requirement that backup software skip copying
> pg_control after a minor release is not OK.
>

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.

Regards,
-David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-10-12 14:54:06 Re: PostgreSQL domains and NOT NULL constraint
Previous Message Tom Lane 2023-10-12 14:34:35 Re: Pro et contra of preserving pg_proc oids during pg_upgrade