Re: Remove Deprecated Exclusive Backup Mode

From: David Steele <david(at)pgmasters(dot)net>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
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-28 15:08:24
Message-ID: a33cc38c-d274-8d00-9fe4-8114523232cb@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/28/19 4:44 PM, Fujii Masao wrote:
> On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>>
>> 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.
>
> Isn't this case problematic even when a backup was taken by pg_basebackup?
> Because of lack of recovery.signal, no archived WAL files are replayed and
> the database may not reach to the latest point.

It is problematic because we have a message encouraging users to delete
backup_label when in fact they should be creating recovery.signal.

If the required WAL is present the cluster will not be corrupted. It
just may not play forward as far as you would prefer.

--
-David
david(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-28 15:09:05 Re: Drop type "smgr"?
Previous Message Joshua Brindle 2019-02-28 15:04:30 Re: Row Level Security − leakproof-ness and performance implications