On Tue, Sep 10, 2019 at 03:23:25PM +0900, Michael Paquier wrote: > Yes, I suspect that it could be very costly in some configurations if > there is a large gap between the last replayed LSN and the last LSN > the WAL receiver has flushed. > > There is an extra thing, which has not been mentioned yet on this > thread, that we need to be very careful about: > <para> > When the standby is started and <varname>primary_conninfo</varname> is > set > correctly, the standby will connect to the primary after replaying all > WAL files available in the archive. If the connection is established > successfully, you will see a walreceiver process in the standby, and > a corresponding walsender process in the primary. > </para> > This is a long-standing behavior, and based on the first patch > proposed we would start a WAL receiver once consistency has been > reached if there is any delay defined even if restore_command is > enabled. We cannot assume either that everybody will want to start a > WAL receiver in this configuration if there is archiving behind with a > lot of segments which allow for a larger catchup window..
Two months later, we still have a patch registered in the CF which is incorrect on a couple of aspects, and with scenarios which are documented and getting broken. Shouldn't we actually have a GUC to control the startup of the WAL receiver instead? -- Michael
signature.asc
Description: PGP signature
