Re: HeapTupleSatisfiesUpdate missing a bet?

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> I got very strange results in my shared-row-locking test today, so I
> took a look at HeapTupleSatisfiesUpdate and came to the conclusion
> that it's delivering the wrong answer in some cases; specifically, it
> returns HeapTupleBeingUpdated for tuples whose Xmax were touched by a
> crashed transaction.

It's not wrong: the transaction *is* in progress, or has to be treated
as such, until you prove differently.

> What do people think of this patch?

It looks like an expensive solution to a non-problem.
TransactionIdIsInProgress isn't particularly cheap and the test will be
wasted 99.999% of the time.

Also, you just introduced a race condition, since the transaction might
have committed after the earlier tests and before you did
TransactionIdIsInProgress. You really have to do
TransactionIdIsInProgress *first*, which makes the proposed change even
more expensive.

What's wrong with using XactLockTableWait? It's not going away --- the
implementation might change but I can't see getting rid of the
functionality.

regards, tom lane