Horton

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

David G. Johnston <david.g.johnston@gmail.com>

View thread View on postgr.es
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, David Steele <david@pgmasters.net>, Michael Paquier <michael@paquier.xyz>, 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-17T18:04:56Z
Lists: pgsql-hackers 
On Tue, Oct 17, 2023 at 10:50 AM Robert Haas <robertmhaas@gmail.com> wrote:

> Life would be a lot easier here if we could get rid of the low-level
> backup API and just have pg_basebackup DTWT, but that seems like a
> completely non-viable proposal.
>

Yeah, my contribution to this area [1] is focusing on the API because I
figured we've provided it and should do our best to have it do as much as
possible for the dba or third-parties that build tooling on top of it.

I kinda think that adding a pg_backup_metadata directory that
pg_backup_start|stop can use may help here.  I'm wondering whether those
functions provide enough control guarantees that pg_control's
"in_backup=true|false" flag proposed in that thread is reliable enough when
copied to the root directory in the backup.  I kinda feel that so long as
the flag is reliable it should be possible for the signal file processing
code to implement whatever protocol we need.

David J.

[1]
https://www.postgresql.org/message-id/CAKFQuwbpz4s8XP_%2BKhsif2eFaC78wpTbNbevUYBmjq-UCeNL7Q%40mail.gmail.com

Commits

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

  2. Acquire ControlFileLock in relevant SQL functions.