Re: Concurrency question

Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> writes:
> On Tue, Jul 7, 2009 at 3:40 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> 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