On Tue, Apr 19, 2011 at 10:28 AM, Steven Parkes <smparkes@smparkes.net> 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
missingsomething? I thought these conflicts were related to queries against the standbys but there shouldn't have been
anythat 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
conflictcase?
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