|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>|
|Cc:||Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Replication & recovery_min_apply_delay|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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:
> 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.
> 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?
|Next Message||Amit Kapila||2019-11-15 02:53:49||Re: cost based vacuum (parallel)|
|Previous Message||Fujii Masao||2019-11-15 02:14:00||Re: could not stat promote trigger file leads to shutdown|