On 2013-11-27 15:14:11 -0800, Kevin Grittner wrote:
> Andres Freund <and...@2ndquadrant.com> wrote:
>
> > HeapTupleHeaderGetUpdateXid() ignores aborted updaters
> > and returns InvalidTransactionId in that case, but
> > HeapTupleSatisfiesVacuum() returns HEAPTUPLE_DELETE_IN_PROGRESS...
>
> That sure *sounds* like it should cause a problem for this code in
> CheckForSerializableConflictOut():
Yea. IMNSHO the current state is a API design flaw. We really should be
returning the aborted xid since that's what happens for non-multixact
ids.
> htsvResult = HeapTupleSatisfiesVacuum(tuple, TransactionXmin, buffer);
> switch (htsvResult)
> {
> [ ... ]
> case HEAPTUPLE_DELETE_IN_PROGRESS:
> xid = HeapTupleHeaderGetUpdateXid(tuple->t_data);
> break;
> [ ... ]
> }
> Assert(TransactionIdIsValid(xid));
>
> ... however, I have not been able to trigger that Assert even with
> gdb breakpoints at what I think are the right spots. Any
> suggestions? How far back is it true that the above
> HeapTupleSatisfiesVacuum() can return HEAPTUPLE_DELETE_IN_PROGRESS
> but HeapTupleHeaderGetUpdateXid(tuple->t_data) on the exact same
> tuple structure can return InvalidTransactionId? Is ther
What do you mean with "how far back"?
> e some
> other condition (besides a ROLLBACK of an UPDATE on the tuple being
> read) which needs to be met? Is any particular timing necessary?
Afaics you need a multixact consisting out of a) the updater and b) a
lock. That's probably easiest to get if you update a row in one session
without changing the primary key, and then key-share lock it in
another. Or the other way round.
Then abort the updater.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
