Re: Reducing relation locking overhead

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Reducing relation locking overhead
Дата
Msg-id 87r78scp08.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Reducing relation locking overhead  (Kevin Brown <kevin@sysexperts.com>)
Список pgsql-hackers
Kevin Brown <kevin@sysexperts.com> writes:

> > The fact that you've been holding the AccessShareLock for quite a
> > long time means that the window for deadlock problems is very wide.
> 
> But with respect to deadlocks, that's true only if deadlocks are
> possible, which is true only if the order of lock acquisition differs
> between transactions.

Taking locks in different orders is one way to trigger deadlocks. But it's not
the only way.

If two threads both take a shared lock on a resource, then try to upgrade it
to an exclusive lock they'll both be waiting on the other thread to release
its shared lock... And in this case they're acquiring the locks in precisely
the same order.

What I don't get from what Tom said was that he implied REINDEX would deadlock
against a regular thread acquiring a plain old exclusive lock even when it's
not also a lock upgrade. It seems to me that REINDEX should be able to get in
and get its exclusive lock and finish its job and then the other job should be
able to get its exclusive lock and complete fine.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: generalizing the planner knobs
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: SERIAL type feature request