Thank you Michael. I agree with you. Relevant part can be removed from the document and eliminate the confusion at least.
Michael Paquier <mich...@paquier.xyz>, 5 Oca 2021 Sal, 10:17 tarihinde şunu yazdı: > 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 >
