Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file
Date
Msg-id E2995C0D-9F02-430D-A787-E3A77FA914F9@amazon.com
Whole thread Raw
In response to Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file
List pgsql-hackers
On 12/2/21, 1:34 PM, "Bossart, Nathan" <bossartn@amazon.com> wrote:
> On 12/2/21, 9:50 AM, "David Steele" <david@pgmasters.net> wrote:
>> On 12/2/21 12:38, David Steele wrote:
>>> On 12/2/21 11:00, Andrew Dunstan wrote:
>>>>
>>>> Should we really be getting rid of
>>>> PostgreSQL::Test::Cluster::backup_fs_hot() ?
>>>
>>> Agreed, it would be better to update backup_fs_hot() to use exclusive
>>> mode and save out backup_label instead.
>>
>> Oops, of course I meant non-exclusive mode.
>
> +1.  I'll fix that in the next revision.

I finally got around to looking into this, and I think I found why it
was done this way in 2018.  backup_fs_hot() runs pg_start_backup(),
closes the session, copies the data, and then runs pg_stop_backup() in
a different session.  This doesn't work with non-exclusive mode
because the backup will be aborted when the session that runs
pg_start_backup() is closed.  pg_stop_backup() will fail with a
"backup is not in progress" error.  Furthermore,
010_logical_decoding_timelines.pl seems to be the only test that uses
backup_fs_hot().

After a quick glance, I didn't see an easy way to hold a session open
while the test does other things.  If there isn't one, modifying
backup_fs_hot() to work with non-exclusive mode might be more trouble
than it is worth.

Nathan


pgsql-hackers by date:

Previous
From: "Euler Taveira"
Date:
Subject: fix libpq comment
Next
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side