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 обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-hackers |
On Thu, Apr 23, 2015 at 2:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> 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 по дате отправления: