From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Code paths where LWLock should be released on failure |
Date: | 2015-04-23 06:03:58 |
Message-ID: | CAB7nPqSNdSmyd=sDX0_N4kKZtRsW=YXr-wXavPQnA9Wc=7miqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 23, 2015 at 2:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2015-04-23 06:26:43 | Re: [BUGS] Failure to coerce unknown type to specific type |
Previous Message | Michael Paquier | 2015-04-23 05:57:59 | Re: Bogus WAL segments archived after promotion |