Re: BUG #8470: 9.3 locking/subtransaction performance regression

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: BUG #8470: 9.3 locking/subtransaction performance regression
Дата
Msg-id 20131223162903.GJ22570@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: BUG #8470: 9.3 locking/subtransaction performance regression  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: BUG #8470: 9.3 locking/subtransaction performance regression  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-bugs
Alvaro Herrera wrote:

> I have more confidence in this patch than in the previous version,
> despite it being more intrusive.  The fact that it allows us to get rid
> of some very strange coding in pgrowlocks is comforting: we now know
> that anytime a tuple is locked we will get BeingUpdated from
> HeapTupleSatisfiesUpdate, regardless of *who* locked it, and all the
> callers are able to identify this case and act in consequence.  This
> seems saner in concept that sometimes returning MayBeUpdated, because
> that turns each such return into a condition that must be double-checked
> by callers.  This means cleaner code in pgrowlocks around a HTSU call,
> for instance.  Also, we have discussed and seriously considered this
> idea in several occasions previously in connection with other things.

... in particular, this change allows us to revert the addition of
MultiXactHasRunningRemoteMembers(), and simply use
MultiXactIdIsRunning() in the two places that required it.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #8470: 9.3 locking/subtransaction performance regression
Следующее
От: Brett Neumeier
Дата:
Сообщение: Re: BUG #8684: Tables with custom range domain type cannot be analyzed