From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Pg_stat_replication shows sync standby with flush location behind primary in 9.1.5 |
Date: | 2012-10-04 07:56:45 |
Message-ID: | 506D413D.6010107@catalyst.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 04/10/12 19:06, Simon Riggs wrote:
> On 4 October 2012 05:32, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> wrote:
>> I am seeing the situation where the reported flush location for the sync
>> standby (standby1 below) is *behind* the reported current xlog location of
>> the primary. This is Postgres 9.1.5 , and I was under the impression that
>> transactions initiated on the master do not commit until the corresponding
>> wal is flushed on the sync standby.
>>
>> Now the standby is definitely working in sync mode, because stopping it
>> halts all write transactions on the primary (sync_standby_names contains
>> only standby1). So is the reported lag in flush location merely an artifact
>> of timing in the query, or is there something else going on? [1]
>
> The writing of new WAL is independent of the wait that occurs on
> commit, so it is entirely possible, even desirable, that the observed
> effect occurs.
>
Ah right - it did occur to me (after posting of course), that *other*
non commit wal could be causing the effect... thank you for clarifying!
This could be worth mentioning in docs for the view - as the context
I've encountered this effect is folks writing scripts for replication
lag etc.
Cheers
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Amit kapila | 2012-10-04 10:12:30 | Re: BUG #7534: walreceiver takes long time to detect n/w breakdown |
Previous Message | Simon Riggs | 2012-10-04 06:06:52 | Re: Pg_stat_replication shows sync standby with flush location behind primary in 9.1.5 |