Re: Code paths where LWLock should be released on failure - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Code paths where LWLock should be released on failure
Date
Msg-id 1852904620.2849232.1429797654025.JavaMail.yahoo@mail.yahoo.com
Whole thread Raw
In response to Re: Code paths where LWLock should be released on failure  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> wrote:

> 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.

Those are not needed for correctness; they are a micro-optimization
for SerializableXactHashLock, which is a particularly hot LWLock
when serializable transactions are used.  There are a few places
where this is not done for this lock, which look like the places
where changes were made late in the development of the feature.
Most probably we went through at one point and added them before
throwing errors when that lock was held (as an optimization), but
neglected to do that with subsequent changes.  Removing the ones
that are there, or adding to the places we could, would not affect
correctness; it might make a very small difference in how quickly a
transaction which is going to cancel due to a serialization failure
gets out of the way of other transactions.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL, RAISE and error context
Next
From: Robert Haas
Date:
Subject: Re: anole - test case sha2 fails on all branches