From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
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-09-03 22:22:56 |
Message-ID: | 20190903222256.GA13633@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-Aug-02, Michael Paquier wrote:
> 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.
Konstantin, any interest in trying this?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-09-03 22:27:11 | Re: SQL/JSON: functions |
Previous Message | Alvaro Herrera | 2019-09-03 22:18:58 | Re: [PATCH] Race condition in logical walsender causes long postgresql shutdown delay |