On 04/10/12 19:06, Simon Riggs wrote:
On 4 October 2012 05:32, Mark Kirkwood <mark.kirkw...@catalyst.net.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
