Re: [HACKERS] 'Waiting on lock'

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] 'Waiting on lock'
Дата
Msg-id 7825.1182274135@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] 'Waiting on lock'  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-patches
Gregory Stark <stark@enterprisedb.com> writes:
> Ok, I understand now that early deadlock detection only kicks in when doing
> something like LOCK TABLE and even then only if you're deadlocking because
> you're upgrading a lock. So this works as intended though it's much less
> useful than I thought.

Yeah, that path is not really intended as an optimization, it's just the
simplest way to clean up correctly at that point, per the comment.  The
part of the whole business that actually *is* useful is where we decide
we should grant ourselves the lock immediately --- if we eliminated that
whole loop and just always queued at the end of the list, we'd still get
the lock, but not till after the deadlock check delay had elapsed.

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: WIP: rewrite numeric division
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] 'Waiting on lock'