Re: Replication & recovery_min_apply_delay

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, 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-08-02 05:44:35
Message-ID: 20190802054435.GE1717@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2019-08-02 05:54:42 Re: Commitfest 2019-07, the first of five* for PostgreSQL 13
Previous Message Amit Langote 2019-08-02 04:55:06 Re: Commitfest 2019-07, the first of five* for PostgreSQL 13