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

On Fri, Jul 14, 2023 at 01:32:49PM -0700, David Zhang wrote:
> I believe before users can make a backup using pg_basebackup and then start
> the backup as an independent Primary server for whatever reasons. Now, if
> this is still allowed, then users need to be aware that the backup_label
> must be manually deleted, otherwise, the backup won't be able to start as a
> Primary.

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.

> The current message below doesn't provide such a hint.
> 
> +		if (!ArchiveRecoveryRequested)
> +			ereport(FATAL,
> +					(errmsg("could not find
> recovery.signal or standby.signal when recovering with
> backup_label"), 
> +					 errhint("If you are restoring
> from a backup, touch \"%s/recovery.signal\" or \"%s/standby.signal\"
> and add required recovery options.",
> +							 DataDir,
> DataDir)));

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.
--
Michael