Re: Replication & recovery_min_apply_delay - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Replication & recovery_min_apply_delay
Date
Msg-id 20190731204326.GA5625@alvherre.pgsql
Whole thread Raw
In response to Re: Replication & recovery_min_apply_delay  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: Replication & recovery_min_apply_delay  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 2019-Jul-31, Konstantin Knizhnik wrote:

> On 08.07.2019 11:05, Michael Paquier wrote:

> > Please note that I have not looked at that stuff in details, but I
> > find the patch proposed kind of ugly with the scan of the last segment
> > using a WAL reader to find out what is the last LSN and react on
> > that..  This does not feel right.
> 
> I am sorry for delay with answer.
> Looks like I have not noticed your reply:(
> Can you explain me please why it is not correct to iterate through WAL using
> WAL reader to get last LSN?

I agree that it's conceptually ugly, but as I mentioned in my previous
reply, I tried several other strategies before giving up and ended up
concluding that this way was a good way to solve the problem.

I don't endorse the exact patch submitted, though.  I think it should
have a lot more commentary on what the code is doing and why.

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.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Unused header file inclusion
Next
From: Tom Lane
Date:
Subject: Re: Unused header file inclusion