Re: Pg_stat_replication shows sync standby with flush location behind primary in 9.1.5
| От | Mark Kirkwood |
|---|---|
| Тема | Re: Pg_stat_replication shows sync standby with flush location behind primary in 9.1.5 |
| Дата | |
| Msg-id | 506D413D.6010107@catalyst.net.nz обсуждение |
| Ответ на | Re: Pg_stat_replication shows sync standby with flush location behind primary in 9.1.5 (Simon Riggs <simon@2ndQuadrant.com>) |
| Список | pgsql-bugs |
On 04/10/12 19:06, Simon Riggs wrote: > On 4 October 2012 05:32, Mark Kirkwood <mark.kirkwood@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
В списке pgsql-bugs по дате отправления: