Re: Rename backup_label to recovery_control - Mailing list pgsql-hackers

From David Steele
Subject Re: Rename backup_label to recovery_control
Date
Msg-id ebefa339-54a2-63fd-10be-f45852e6b893@pgmasters.net
Whole thread Raw
In response to Re: Rename backup_label to recovery_control  (Michael Banck <mbanck@gmx.net>)
List pgsql-hackers

On 10/16/23 12:06, Michael Banck wrote:
> On Mon, Oct 16, 2023 at 11:15:53AM -0400, David Steele wrote:
>> On 10/16/23 10:19, Robert Haas wrote:
>>> We got rid of exclusive backup mode. We replaced pg_start_backup
>>> with pg_backup_start.
>>
>> I do think this was an improvement. For example it allows us to do
>> [1], which I believe is a better overall solution to the problem of
>> torn reads of pg_control. With exclusive backup we would not have this
>> option.
> 
> Well maybe, but it also seems to mean that any other 3rd party (i.e. not
> Postgres-specific) backup tool seems to only support Postgres up till
> version 14, as they cannot deal with non-exclusive mode - they are used
> to a simple pre/post-script approach.

I'd be curious to know what enterprise solutions currently depend on 
this method. At the very least they'd need to manage a WAL archive since 
copying pg_wal is not a safe thing to do (without a snapshot), so it's 
not just a matter of using start/stop scripts. And you'd probably want 
PITR, etc.

> Not sure what to do about this, but as people/companies start moving to
> 15, I am afraid we will get people complaining about this. I think
> having exclusive mode still be the default for pg_start_backup() (albeit
> deprecated) in one release and then dropping it in the next was too
> fast.

But lots of companies are on PG15 and lots of hosting providers support 
it, apparently with no issues. Perhaps the companies you are referring 
to are lagging in adoption (a pretty common scenario) but I still see no 
evidence that there is a big problem looming.

Exclusive backup was deprecated for six releases, which should have been 
ample time to switch over. All the backup solutions I am familiar with 
have supported non-exclusive backup for years.

> Or is somebody helping those "enterprise" backup solutions along in
> implementing non-exclusive Postgres backups?

I couldn't say, but there are many examples in open source projects of 
how to do this. Somebody (Laurenz, I believe) also wrote a shell script 
to simulate exclusive backup behavior for those that want to continue 
using it. Not what I would recommend, but he showed that it was possible.

Regards,
-David



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: The danger of deleting backup_label
Next
From: David Steele
Date:
Subject: Re: Rename backup_label to recovery_control