Re: [COMMITTERS] pgsql: Replication lag tracking for walsenders

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

In response to

Responses

Browse pgsql-committers by date

  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

Browse pgsql-hackers by date

  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