Re: Code paths where LWLock should be released on failure

Michael Paquier <michael(dot)paquier(at)gmail(dot)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