Re: uninterruptable loop: concurrent delete in progress within table

Robert Haas <robertmhaas@gmail.com> writes:
> What specifically do you think will break?  For example, in
> HeapTupleSatisfiesMVCC(), if no xmax-related hint bits are set, it
> looks to me like we'll end up here:

>         if (!TransactionIdDidCommit(HeapTupleHeaderGetRawXmax(tuple)))
>         {
>             /* it must have aborted or crashed */
>             SetHintBits(tuple, buffer, HEAP_XMAX_INVALID,
>                         InvalidTransactionId);
>             return true;
>         }

> Well, TransactionIdDidCommit() will call TransactionLogFetch() which
> has a special case coding to handle non-normal transaction IDs, which
> for InvalidTransactionId will return TRANSACTION_STATUS_ABORTED.  Now
> maybe that is dead code and always has been, but that wouldn't be my
> bet going into it: I bet that got there for a reason.

No, the code to return that for InvalidTransactionId is just there because
it has to do *something*, and returning status COMMITTED is clearly not
too sane.  I don't believe there was ever any expectation that xmax equal
to InvalidTransactionId would not have the XMAX_INVALID hint bit set.
If anyone had thought about that case, they'd probably have chosen to
put in a should-not-happen error for it, because it strongly suggests
you're looking at corrupted data.

            regards, tom lane