Re: Rename backup_label to recovery_control

From: David Steele <david(at)pgmasters(dot)net>
To: Michael Banck <mbanck(at)gmx(dot)net>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Rename backup_label to recovery_control
Date: 2023-10-16 17:16:19
Message-ID: ebefa339-54a2-63fd-10be-f45852e6b893@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2023-10-16 17:23:32 Re: Rename backup_label to recovery_control
Previous Message David Steele 2023-10-16 17:00:11 Re: The danger of deleting backup_label