Re: Replication & recovery_min_apply_delay - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Replication & recovery_min_apply_delay
Date
Msg-id ca106468-24c6-9f72-b37d-7d5d43f224ed@postgrespro.ru
Whole thread Raw
In response to Re: Replication & recovery_min_apply_delay  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Replication & recovery_min_apply_delay
List pgsql-hackers

On 08.07.2019 11:05, Michael Paquier wrote:
> On Mon, Jul 08, 2019 at 07:56:25PM +1200, Thomas Munro wrote:
>> On Thu, Jan 31, 2019 at 3:34 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>>> On 2019-Jan-30, Konstantin Knizhnik wrote:
>>>> I wonder if it can be considered as acceptable solution of the problem or
>>>> there can be some better approach?
>>> I didn't find one.
>> It sounds like you are in agreement that there is a problem and this
>> is the best solution.  I didn't look at these patches, I'm just asking
>> with my Commitfest manager hat on: did I understand correctly, does
>> this need a TAP test, possibly the one Alvaro posted, and if so, could
>> we please have a fresh patch that includes the test, so we can see it
>> passing the test in CI?
> 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.
> --
> Michael

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?
 From my point of view it may be not so efficient way, but it should 
return correct value, shouldn't it?
Can you suggest some better way to calculate last LSN?

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




pgsql-hackers by date:

Previous
From: Sehrope Sarkuni
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench - implement strict TPC-B benchmark