Re: Concurrency question

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Concurrency question
Дата
Msg-id 29706.1247004713@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Concurrency question  (Scott Marlowe <scott.marlowe@gmail.com>)
Ответы Re: Concurrency question  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: Concurrency question
Следующее
От: Jennifer Spencer
Дата:
Сообщение: Re: Catching up Production from Warm Standby after maintenance - Please help