Re: Remove Deprecated Exclusive Backup Mode

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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 21:44:46
Message-ID: CABUevEyU9hkfwztmRO+2amJApJ5Kgtkyvn53XffzZrGMfOo5Gg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 1, 2020 at 11:08 PM David Steele <david(at)pgmasters(dot)net> wrote:

> On 7/1/20 4:39 PM, Magnus Hagander wrote:
> > On Wed, Jul 1, 2020 at 10:28 PM David Steele <david(at)pgmasters(dot)net
> > 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.
> >
> > I guess the weak spot of that one is if some script does stop without
> > doing start first, it will break somebody else's backup. (And yes, I've
> > seen scripts make this mistake many times -- it equally breaks the
> > exclusive backups in the current system...)
>
> Well, they'd have to pass in a backup_label with a start LSN >= the min
> LSN or they would just get an error and not decrement the backup count.
>

Oh as long as we're still requiring pg_stop_backup() to pass in something
that it received from pg_start_backup() so that we can verify it's the
correct one, then that problem wouldn't exist.

The real issue would be if they called pg_stop_backup twice. We might be
> able to stop that with a rolling max stop lsn to keep anyone from
> calling pg_stop_backup() twice.

> But yeah, it would be possible to kill somebody else's session with some
> finagling. Still, worse case would be an error'd backup rather than a
> corrupt one.
>

What about the case of:
Session A - start backup
Session B - stop backup (but A is still running of course)
Session C - start backup
Session A - stop backup

At this point, session A can still stop the backup because there is one
running -- but there has been time in between the two when no backup was
running. That could lead to Session A getting a corrupt backup, I think --
unless we pass some unique identifier back in pg_stop_backup that matches
it up. (And if we do pass that up, then session B running pg_stop_backup()
would fail, thus leaving the backup started by A still running.

But really, that's only if FPWs are turned off. We can also do some
> extra validation if the session is left open, which for most software is
> the norm now.
>

Session left open should really still be the default, as it's the safest
one :) And yes, most backup *software* does it. But the entire reason we
want another mode from the current non-exclusive backup is people *not*
using one of the ready-made backup solutions.

> And don't we need the combination of the start/stop location for the
> > history file?
>
> You mean the .backup file for the WAL? All that needs is the
> backup_label and the stop LSN that's determined in pg_stop_backup(). Am
> I missing something?
>

I mean the .backup file in the archive, yes. That one contains both the
start and the stop location, timeline and time.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-07-01 22:17:22 Re: Inlining of couple of functions in pl_exec.c improves performance
Previous Message Joe Conway 2020-07-01 21:43:37 Re: pg_read_file() with virtual files returns empty string