Re: Concurrency question - Mailing list pgsql-admin

From Tom Lane
Subject Re: Concurrency question
Date
Msg-id 29706.1247004713@sss.pgh.pa.us
Whole thread Raw
In response to Re: Concurrency question  (Scott Marlowe <scott.marlowe@gmail.com>)
Responses Re: Concurrency question
List pgsql-admin
Scott Marlowe <scott.marlowe@gmail.com> writes:
> On Tue, Jul 7, 2009 at 3:40 PM, Tom Lane<tgl@sss.pgh.pa.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

pgsql-admin by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Concurrency question
Next
From: Jennifer Spencer
Date:
Subject: Re: Catching up Production from Warm Standby after maintenance - Please help