Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders
Date
Msg-id 300.1492927294@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Sun, Apr 23, 2017 at 3:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> As for this patch itself, is it reasonable to try to assert that the
>> timeline has in fact changed?

> The protocol doesn't include the timeline in reply messages, so it's
> not clear how the upstream server would know what timeline the standby
> thinks it's dealing with in any given reply message.  The sending
> server has its own idea of the current timeline but it's not in sync
> with the stream of incoming replies.

Fair enough.  But I'd still like an explanation of why only about
half of the population is showing a failure here.  Seems like every
machine should be seeing the LSN as moving backwards in this test.
So (a) why aren't they all failing, and (b) should we change the
test to make sure every platform sees that happening?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders
Next
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] recovery tests vs windows