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

On Thu, Sep 28, 2023 at 04:23:42PM -0400, David Steele wrote:
> After some playing around, I find I agree with Michael on this, i.e. require
> at least standby.signal when a backup_label is present.
>
> According to my testing, you can preserve the "independent server"
> functionality by setting archive_command = /bin/false. In this case the
> timeline is not advanced and recovery proceeds from whatever is available in
> pg_wal.

I've seen folks depend on such setups in the past, actually, letting a
process outside Postgres just "push" WAL segments to pg_wal instead of
Postgres pulling it with a restore_command or a primary_conninfo for a
standby.

> I think this type of recovery from a backup label without a timeline change
> should absolutely be the exception, not the default as it seems to be now.

This can mess up archives pretty easily, additionally, so it's not
something to encourage..

> If the server is truly independent, then the timeline change is not
> important. If the server is not independent, then the timeline change is
> critical.
>
> So overall, +1 for Michael's patch, though I have only read through it and
> not tested it yet.

Reviews, thoughts and opinions are welcome.

> One comment, though, if we are going to require recovery.signal when
> backup_label is present, should it just be implied? Why error and force the
> user to create it?

That's one thing I was considering, but I also cannot convince myself
that this is the best option because the presence of recovery.signal
or standby.standby (if both, standby.signal takes priority) makes it
clear what type of recovery is wanted at disk level. I'd be OK if
folks think that this is a sensible consensus, as well, even if I
don't really agree with it.

Another idea I had was to force the creation of recovery.signal by
pg_basebackup even if -R is not used. All the reports we've seen with
people getting confused came from pg_basebackup that enforces no
configuration.

A last thing, that had better be covered in a separate thread and
patch, is about validateRecoveryParameters(). These days, I'd like to
think that it may be OK to lift at least the restriction on
restore_command being required if we are doing recovery to ease the
case of self-contained backups (aka the case where all the WAL needed
to reach a consistent point is in pg_wal/ or its tarball)
--
Michael