Re: lazy_truncate_heap()

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