Re: uninterruptable loop: concurrent delete in progress within table

Robert Haas <robertmhaas(at)gmail(dot)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