Re: Code paths where LWLock should be released on failure

Поиск
Список
Период
Сортировка
Искать
От
Michael Paquier
Тема
Re: Code paths where LWLock should be released on failure
Дата
Msg-id
CAB7nPqSNdSmyd=sDX0_N4kKZtRsW=YXr-wXavPQnA9Wc=7miqg@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Code paths where LWLock should be released on failure Michael Paquier <michael.paquier@gmail.com>
Re: Code paths where LWLock should be released on failure Tom Lane <tgl@sss.pgh.pa.us>
Re: Code paths where LWLock should be released on failure Michael Paquier <michael.paquier@gmail.com>
Re: Code paths where LWLock should be released on failure Kevin Grittner <kgrittn@ymail.com>
Re: Code paths where LWLock should be released on failure Andres Freund <andres@anarazel.de>
On Thu, Apr 23, 2015 at 2:46 PM, Tom Lane  wrote:
> Michael Paquier  writes:
>> After looking at bug #13128, I have been looking at the code around
>> LWLockAcquire/Release to see if there are similar issues elsewhere.
>> Here are my findings:
>
> IIRC, we automatically release all LWLocks at the start of error recovery,
> so I rather doubt that any of this is necessary.

Perhaps this is purely cosmetic for most those code, but not all... if
you have a look at #13128, not releasing TwoPhaseStateLock causes a
deadlock on startup when max_prepared_transactions does not have
enough slots. I have also been surprised by the inconsistencies
particularly in predicate.c or other places regarding LWLock releases.
Sometimes they are released on failure, sometimes not.
Regards,
-- 
Michael


В списке pgsql-hackers по дате отправления
От: Michael Paquier
Дата:
От: Jeff Davis
Дата:
FAQ