From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Replication lag tracking for walsenders |
Date: | 2017-04-23 06:01:34 |
Message-ID: | 300.1492927294@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Sun, Apr 23, 2017 at 3:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-04-23 10:10:33 | Re: [COMMITTERS] pgsql: Replication lag tracking for walsenders |
Previous Message | Tom Lane | 2017-04-23 05:26:46 | Re: [COMMITTERS] pgsql: Replication lag tracking for walsenders |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2017-04-23 07:42:25 | Re: recovery tests vs windows |
Previous Message | Tom Lane | 2017-04-23 05:26:46 | Re: [COMMITTERS] pgsql: Replication lag tracking for walsenders |