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/>
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 |