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]
db=# SELECT
application_name,pg_current_xlog_location(),sent_location,write_location,flush_location,replay_location,sync_priority,state
FROM pg_stat_replication where replay_location is not null;
application_name | pg_current_xlog_location | sent_location |
write_location | flush_location | replay_location | sync_priority | state
------------------+--------------------------+---------------+----------------+----------------+-----------------+---------------+-----------
standby1 | E/254909E0 | E/25490000 |
E/2548C3B8 | E/2548C3B8 | E/25476DE0 | 1 |
streaming <===
standby2 | E/254909E0 | E/2548C3B8 |
E/25476DE0 | E/25476DE0 | E/254724C0 | 0 | streaming
standby3 | E/254909E0 | E/254909E0 |
E/25476DE0 | E/25476DE0 | E/254724C0 | 0 | streaming
standby4 | E/254909E0 | E/25490000 |
E/2548C3B8 | E/25476DE0 | E/25476DE0 | 0 | streaming
standby5 | E/254909E0 | E/25490000 |
E/25476DE0 | E/25476DE0 | E/254724C0 | 0 | streaming
(5 rows)
Cheers
Mark
[1] Looking at the code for pg_stat_replication, it appears to take the
sync rep lock while reporting, so in theory should be exactly right...I
should perhaps check what pg_current_xlog_location does...
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
