From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MultiXact truncation, startup et al. |
Date: | 2013-11-29 19:58:06 |
Message-ID: | 20131129195806.GA6237@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-11-29 16:30:08 -0300, Alvaro Herrera wrote:
> New versions of all these patches, plus one more patch which removes the
> behavior that HeapTupleGetUpdateXid checks for aborted updates.
> From 0dce0b75da2732ca93f4c451b9bae6d4416794c3 Mon Sep 17 00:00:00 2001
> From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> Date: Fri, 29 Nov 2013 16:08:06 -0300
> Subject: [PATCH 4/5] Don't TransactionIdDidAbort in HeapTupleGetUpdateXid
>
> It is dangerous to do so, because some code expects to be able to see what's
> the true Xmax even if it is aborted (particularly while traversing HOT
> chains). So don't do it, and instead rely on the callers to verify for
> abortedness, if necessary.
>
> Several race conditions and bugs fixed in the process.
The current version of that additional patch causes two failures in
isolationtester's delete-abort-savept.spec/out. But afaics the old
behaviour was a bug: An updater seems to have waited for an aborted
subtransaction.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2013-11-29 20:06:07 | Re: [RFC] overflow checks optimized away |
Previous Message | Greg Stark | 2013-11-29 19:39:55 | Re: [RFC] overflow checks optimized away |