On Tue, Apr 19, 2011 at 10:28 AM, Steven Parkes <smparkes@xxxxxxxxxxxx> wrote: >> Did you run query on the standby? > > Yup. Both standbys. They both responded the same way. > >> If yes, I guess that query conflict prevented >> the reply location from advancing. >> http://www.postgresql.org/docs/9.0/static/hot-standby.html#HOT-STANDBY-CONFLICT > > The standbys were idle and this was a persistent state. I restarted the standbys and they stayed in this state. Am I missing something? I thought these conflicts were related to queries against the standbys but there shouldn't have been any that I'm aware. Certainly none should survive a restart ... > > Am I missing something about the conflict? > > It also seems notable that a new commit on the master cleared the issue ... Does that seem like the hot standby conflict case? Probably no. Was there idle-in-transaction in the master when the problem happened? If yes, this can happen. In that case, only half of WAL record can be written to the disk by walwriter and sent to the standby by walsender. The rest will be written and sent after you'll have finished the transaction. In this case, the receive location indicates the end of that WAL record obviously. OTOH, since that half-baked WAL record cannot be replayed, the replay location cannot advance and still has to indicate the end of previous WAL record. If you issue new commit, all of the WAL record is flushed to the standby. So that WAL record was replayed and the replay location advanced. I guess you observed the above situation. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
