On 2/28/19 4:44 PM, Fujii Masao wrote:
> On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe <laurenz.albe@cybertec.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@pgmasters.net
