Re: Rename backup_label to recovery_control

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: Rename backup_label to recovery_control
Дата
Msg-id ebefa339-54a2-63fd-10be-f45852e6b893@pgmasters.net
обсуждение исходный текст
Ответ на Re: Rename backup_label to recovery_control  (Michael Banck <mbanck@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: The danger of deleting backup_label
Следующее
От: David Steele
Дата:
Сообщение: Re: Rename backup_label to recovery_control