Alvaro Herrera <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
