On Sun, 2009-01-04 at 13:01 +0200, Heikki Linnakangas wrote:
> Why does an AccessExclusiveLock lead to cancelled queries
> >> or pausing WAL application? I thought it'd just block other queries
> >> trying to acquire a conflicting lock in the standby, just like holding
> >> an AccessExclusiveLock on the primary does. It's unrelated to the xmin
> >> horizon issue.
> >
> > Yes, it is unrelated to the xmin horizon issue. There are two reasons
> > for delaying WAL apply:
> > * locks
> > * xmin horizon
> >
> > When a lock is acquired on the primary it almost always precedes an
> > action which cannot occur concurrently. For example, if VACUUM did
> > truncate a table then queries could get errors because parts of their
> > table disappear from under them. Others are drop table etc..
>
> Have you implemented the query cancellation mechanism for that scenario
> too? (I'm cool either way, just curious..)
Yes, they both lead to a conflict between WAL and standby queries, so
are treated the same, currently: if conflict occurs, wait until
max_standby_delay expires, then cancel.
Logically, "xmin horizon" conflicts could be flexible/soft. That is, if
we implemented the idea to store a lastCleanedLSN for each buffer then
"xmin horizon" conflicts would be able to continue executing until they
see a buffer with buffer.lastCleanedLSN > conflictLSN. Whereas the lock
would be a hard limit beyond which a query could not progress.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
