Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

From: David Zhang <david(dot)zhang(at)highgo(dot)ca>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
Date: 2023-07-19 18:21:17
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2023-07-16 6:27 p.m., Michael Paquier wrote:
> Delete a backup_label from a fresh base backup can easily lead to data
> corruption, as the startup process would pick up as LSN to start
> recovery from the control file rather than the backup_label file.
> This would happen if a checkpoint updates the redo LSN in the control
> file while a backup happens and the control file is copied after the
> checkpoint, for instance. If one wishes to deploy a new primary from
> a base backup, recovery.signal is the way to go, making sure that the
> new primary is bumped into a new timeline once recovery finishes, on
> top of making sure that the startup process starts recovery from a
> position where the cluster would be able to achieve a consistent
> state.
Thanks a lot for sharing this information.
> How would you rewrite that? I am not sure how many details we want to
> put here in terms of differences between recovery.signal and
> standby.signal, still we surely should mention these are the two
> possible choices.

Honestly, I can't convince myself to mention the backup_label here too.
But, I can share some information regarding my testing of the patch and
the corresponding results.

To assess the impact of the patch, I executed the following commands for
before and after,

pg_basebackup -h localhost -p 5432 -U david -D pg_backup1

pg_ctl -D pg_backup1 -l /tmp/logfile start

Before the patch, there were no issues encountered when starting an
independent Primary server.

However, after applying the patch, I observed the following behavior
when starting from the base backup:

1) simply start server from a base backup

FATAL:  could not find recovery.signal or standby.signal when recovering
with backup_label

HINT:  If you are restoring from a backup, touch
"/media/david/disk1/pg_backup1/recovery.signal" or
"/media/david/disk1/pg_backup1/standby.signal" and add required recovery

2) touch a recovery.signal file and then try to start the server, the
following error was encountered:

FATAL:  must specify restore_command when standby mode is not enabled

3) touch a standby.signal file, then the server successfully started,
however, it operates in standby mode, whereas the intended behavior was
for it to function as a primary server.

Best regards,


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message John Morris 2023-07-19 18:55:10 Re: Atomic ops for unlogged LSN
Previous Message Justin Pryzby 2023-07-19 18:13:48 Re: ALTER TABLE SET ACCESS METHOD on partitioned tables