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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
