From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Adrien NAYRAT <adrien(dot)nayrat(at)anayrat(dot)info>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Remove Deprecated Exclusive Backup Mode |
Date: | 2019-02-27 07:35:21 |
Message-ID: | 0abba229ff2dd18d174234433fcf5ac5938b03b4.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao wrote:
> So, let me clarify the situations;
>
> (3) If backup_label.pending exists but recovery.signal doesn't, the server
> ignores (or removes) backup_label.pending and do the recovery
> starting the pg_control's REDO location. This case can happen if
> the server crashes while an exclusive backup is in progress.
> So crash-in-the-middle-of-backup doesn't prevent the recovery from
> starting in this idea
That's where I see the problem with your idea.
It is fairly easy for someone to restore a backup and then just start
the server without first creating "recovery.signal", and that would
lead to data corruption.
Indeed, if I didn't know much about databases and were faced with
the task of restoring a PostgreSQL database from backup in a hurry,
that is probably what I would do.
Having thought some about the whole problem area, I believe that there
is no safe way to disambiguate a backup from a server crashed in backup
mode.
The non-exclusive backup mode actually suffers from a similar problem ---
if you don't add "backup_label" to the backup afterwards, it will lead
to database corruption.
The only fool-proof tool we have in core is pg_basebackup.
Any really good backup solution that wishes to integrate with a third-
party backup tool will have to get that tool to include "backup_label"
with the backup itself.
For that, it would need to know the contents of "backup_label" *before*
pg_stop_backup(). Is there a good reason why it is pg_stop_backup()
and not pg_start_backup() that provides that information?
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-02-27 07:47:28 | get_controlfile() can leak fds in the backend |
Previous Message | Michael Paquier | 2019-02-27 07:31:24 | Re: [HACKERS] generated columns |