Re: pg_rewind restore_command issue in PG12

On Mon, Jan 04, 2021 at 04:12:34PM +0300, Amine Tengilimoglu wrote:
> When I read the pg_rewind PG12 doc. It says:
>
> "... but if the target cluster ran for a long time after the divergence,
> the old WAL files might no longer be present. In that case, they can be
> manually copied from the WAL archive to the pg_wal directory,* or fetched
> on startup by configuring **primary_conninfo
> <https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-PRIMARY-CONNINFO>
> or restore_command
> <https://www.postgresql.org/docs/12/runtime-config-wal.html#GUC-RESTORE-COMMAND>*
> .".
>
> So I thought we could use restore_command. But when I try to use it , I
> see it doesn't work either.

I agree with your point that the docs of 9.6~12 are confusing here.
It makes no sense to mention restore_command or primary_conninfo to
fetch WAL segments for the target to allow pg_rewind to find the point
of divergence because the target is already offline when we look at
that. Mentioning restore_command/primary_conninfo for recovery
purposes could make sense in the context in the follow-up paragraph
though, where the target gets restarted, after the rewind. But the
uses are different.

The docs of 13~ got that right when -c has been introduced by
rewording this sentence as "or run pg_rewind with the -c option to
automatically retrieve them from the WAL archive". So let's get rid
of ", or fetched on startup by configuring primary_conninfo or
restore_command." ("or fetched on startup by configuring
recovery.conf" in some older branches). This confusion has been
introduced by 878bd9a, down to 9.6.

Heikki, what do you think?
--
Michael