Simon Riggs wrote:
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..
Have you implemented the query cancellation mechanism for that scenario
too? (I'm cool either way, just curious..)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
