Re: Remove Deprecated Exclusive Backup Mode

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Remove Deprecated Exclusive Backup Mode
Date: 2020-07-01 20:34:12
Message-ID: CA+TgmoZrRLrRByU_C03td2EBv3BniSNE6rhRC-0LHXYsuRi6qA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 1, 2020 at 4:27 PM David Steele <david(at)pgmasters(dot)net> wrote:
> Well, the only thing pg_stop_backup() *really* needs to know is the
> starting WAL position. pg_start_backup() gets that info so if it passes
> it back to pg_stop_backup() that could be enough. Or as was proposed
> above, it just passes the backup_label back to pg_stop_backup() for
> parsing. To write the .backup file to WAL (which I personally think is
> pretty useless) you'd need backup_label.
>
> The issue I have not been able to work around is that full page writes
> need to be on for backups and they won't get turned back off if you
> don't end all the backups that get started.
>
> Here's a thought. What if we just stored the oldest starting LSN and a
> count of how many backups have been requested. When the backup ends it
> checks that backup count is > 0 and starting LSN is <= its starting LSN.
> If not, it throws an error. When backups go to 0 FPWs are turned off if
> they were off before the first backup.
>
> That way, we could have a single function to cancel all backups in
> progress. Even if a new one started, one ending that was started prior
> to the cancel would know that it could not end successfully and error.
>
> For the vast majority of people who have full page writes on, it
> wouldn't really matter how many backups were running so we could
> probably just skip all of that.

Yeah, I like this line of thinking. Not sure about the details.

> If we wanted to really make it more foolproof we could add a checksum to
> the backup label to make sure the user doesn't damage it before passing
> it back.

I don't see a whole lot of point in that, honestly. It doesn't make it
impossible to damage the backup label; it just makes it harder. And
that doesn't seem worth much.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2020-07-01 20:34:18 Re: SQL-standard function body
Previous Message Bruce Momjian 2020-07-01 20:33:54 Re: max_slot_wal_keep_size and wal_keep_segments