Re: Code paths where LWLock should be released on failure

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Code paths where LWLock should be released on failure
Дата
Msg-id 1852904620.2849232.1429797654025.JavaMail.yahoo@mail.yahoo.com
обсуждение исходный текст
Ответ на Re: Code paths where LWLock should be released on failure  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: PL/pgSQL, RAISE and error context
Следующее
От: Robert Haas
Дата:
Сообщение: Re: anole - test case sha2 fails on all branches