On Thu, 2009-01-01 at 12:00 +0200, Heikki Linnakangas wrote: > Greg Stark wrote: > > > > On 31 Dec 2008, at 13:21, Simon Riggs <si...@2ndquadrant.com> wrote: > >> > >> Both of these bugs are minor, but the effect of either/both of them is > >> to cause more AccessExclusiveLocks than we might expect. > >> > >> For Hot Standby this means that many VACUUMs take AccessExclusiveLocks > >> on relations, which would potentially lead to having queries cancelled > >> for no reason at all. > > > > Well by default it would just cause wal to pause briefly until the > > queries with those locks finish, no? > > Wait a minute. 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.. -- 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
