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

From Thomas Munro
Subject Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders
Date
Msg-id CAEepm=3N59Qi=Mo0mb1SmHVdEryb+jdtqEvmsp60bBVBeF+eVQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Sat, Apr 22, 2017 at 9:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Simon Riggs wrote:
>>> Replication lag tracking for walsenders
>>>
>>> Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication.
>
>> Did anyone notice that this seems to be causing buildfarm member 'tern'
>> to fail the recovery check?  See here:
>
>> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=tern&dt=2017-04-21%2012%3A48%3A09&stg=recovery-check
>> which has
>> TRAP: FailedAssertion("!(lsn >= prev.lsn)", File: "walsender.c", Line: 3331)
>
>> Line 3331 was added by this commit.
>
> Note that while that commit was some time back, tern has only just started
> running recovery-check, following its update to the latest buildfarm
> script.  It looks like it's run that test four times and failed twice,
> so far.  So, not 100% reproducible, but there's something rotten there.
> Timing-dependent, maybe?

Thanks.  I'm away from my computer right now but will investigate this
and send a fix later today.

-- 
Thomas Munro
http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] snapbuild woes
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Unportable implementation of background worker start