Re: Replication & recovery_min_apply_delay - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Replication & recovery_min_apply_delay
Date
Msg-id 20190802054435.GE1717@paquier.xyz
Whole thread Raw
In response to Re: Replication & recovery_min_apply_delay  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Replication & recovery_min_apply_delay  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Wed, Jul 31, 2019 at 04:43:26PM -0400, Alvaro Herrera wrote:
> As for the test module, the one I submitted takes a lot of time to run
> (well, 60s) and I don't think it's a good idea to include it as
> something to be run all the time by every buildfarm member.  I'm not
> sure that there's a leaner way to test for this bug, though, but
> certainly it'd be a good idea to ensure that this continues to work.

Hmmm.  Instead of that, wouldn't it be cleaner to maintain in the
context of the startup process a marker similar to receivedUpto for
the last LSN?  The issue with this one is that it gets reset easily so
we would lose track of it easily, and we need also to count with the
case where a WAL receiver is not started.  So I think that we should
do that as a last replayed or received LSN if a WAL receiver is up and
running, whichever is newer.  Splitting the WAL receiver restart logic
into a separate routine is a good idea in itself, the patch attempting
to switch primary_conninfo to be reloadable could make use of that.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Commitfest 2019-07, the first of five* for PostgreSQL 13
Next
From: Julien Rouhaud
Date:
Subject: Re: Commitfest 2019-07, the first of five* for PostgreSQL 13