> Was there idle-in-transaction in the master when the problem happened?
Shouldn't have been, but that's what I was wondering, too. I didn't check. Not
sure I know how to check.
That was my guess and I mostly wanted to confirm that that could happen. Does
seem like an edge case. I don't expect
On Tue, Apr 19, 2011 at 10:28 AM, Steven Parkes 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.ht
> 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 p
On Tue, Apr 19, 2011 at 9:00 AM, Steven Parkes wrote:
> This is on 9.0.3: I've got two dbs running as standby to a main db. They
> start up fine and seem to think they're all caught up (by /var/log logs), but
>
> SELECT pg_last_xlog_receive_location() AS receive,
> pg_last_xlog_replay_location()
This is on 9.0.3: I've got two dbs running as standby to a main db. They start
up fine and seem to think they're all caught up (by /var/log logs), but
SELECT pg_last_xlog_receive_location() AS receive,
pg_last_xlog_replay_location() AS replay;
reports replay behind receive and it doesn't change
