Re: MultiXact bugs

On 2013-11-29 13:14:06 -0800, Kevin Grittner wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > On 2013-11-27 15:42:11 -0800, Kevin Grittner wrote:
>
> >> What back-patching will be needed for a fix?  It sounds like
> >> 9.3?
> >
> > Yep.
>
> In going over this, I found pre-existing bugs when a tuple was both
> inserted and deleted by concurrent transactions, but fixing that is
> too invasive to consider for Monday's minor release lockdown.  The
> attached seems very safe to me, and protects against some new
> hazards related to the subtransaction changes (mostly just for an
> assert-enabled build, but still worth fixing).  It includes a lot
> of work on the comments, to guide the subsequent fixes or other
> work in that area.

> If nobody objects, I will push it to master and 9.3 tomorrow.

Alvaro is about to commit a patch that will remove the behaviour of
GetUpdateXid() to check for IdDidAbort() because it makes other fixes
really complicated and it's a really suprising behaviour. But most of
your patch shouldn't be affected by that.
Check
http://archives.postgresql.org/message-id/20131129193008.GP5513%40eldon.alvh.no-ip.org
for the current state of the series.

Looking at predicate.c I think I see a bigger problem though: Isn't its
usage of HeapTupleSatisfiesVacuum() quite dangerous? It passes
TransactionXmin to HeapTupleSatisfiesVacuum(). But since that's just the
transaction's own cutoff, not the global cutoff that will cause wrong
hint bits to be set. Or am I missing something?
HTSV's comment says:
*
* OldestXmin is a cutoff XID (obtained from GetOldestXmin()). Tuples
* deleted by XIDs >= OldestXmin are deemed "recently dead"; they might
* still be visible to some open transaction, so we can't remove them,
* even if we see that the deleting transaction has committed.
*/

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services