Re: Replication & recovery_min_apply_delay

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: 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
Date: 2019-11-15 15:48:01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 15.11.2019 5:52, Michael Paquier wrote:
> 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

Attached pleased find rebased version of the patch with
"wal_receiver_start_condition" GUC added (preserving by default original

Konstantin Knizhnik
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
wal_apply_delay-2.patch text/x-patch 6.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-11-15 16:22:20 Re: SKIP_LOCKED test causes random buildfarm failures
Previous Message Alexey Kondratov 2019-11-15 15:24:41 Re: Conflict handling for COPY FROM