Scott Marlowe <scott.marlowe@xxxxxxxxx> writes: > On Tue, Jul 7, 2009 at 3:40 PM, Tom Lane<tgl@xxxxxxxxxxxxx> wrote: >> The described situation is impossible: AccessSharelock doesn't block >> ShareUpdateExclusiveLock. There must have been some other lock or >> attempted lock involved (perhaps at a page or tuple level rather than >> the whole-relation level). But we can't tell much from this much detail. > So something like alter table or something? Well, one possible way to block vacuum is that the idle transaction is holding AccessSharelock, and some third session is trying to acquire an exclusive lock (eg for ALTER TABLE), and then vacuum comes along and wants ShareUpdateExclusiveLock. That would cause vacuum to queue up behind the waiting exclusive lock request. However, Mark asserts that the vacuum did successfully acquire ShareUpdateExclusiveLock, which if accurate would eliminate this scenario. But there might have been something similar going on at a page or tuple level. We can't tell with no knowledge of what else was in the system, but I'm betting there was at least one other lock request involved. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
