Re: Incorrect UPDATE trigger invocation in the UPDATE clause of an UPSERT statement.

On Tue, Dec 8, 2015 at 1:17 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> I think you might be confusing ExecUpdate()'s use of
> HeapTupleSelfUpdated with ExecOnConflictUpdate()'s similar use of
> HeapTupleInvisible (where it's almost the same to the user -- it's the
> "I guess we'll throw a cardinality violation error to reject a second
> attempt at updating the tuple" state there). And, contrariwise,
> ExecUpdate() has HeapTupleInvisible as its own "can't happen" error.
> Of course, these differences are due to the different types of
> snapshots used in each case (dirty snapshot for
> ExecOnConflictUpdate(), MVCC snapshot for ExecUpdate() -- at least
> prior to 9.5/this bug).

Note that it's possible for ExecOnConflictUpdate() to never see a
HeapTupleSelfUpdated case (it is, as I said, a "can't happen"
condition), and yet for its ExecUpdate call to see a
HeapTupleSelfUpdated case with odd queries like the with.sql test
Andres highlighted.

This is only because, as Andres said, ExecProject() and so on can
change things. But things cannot change between finding a conflict TID
in the first stage, and returning from heap_lock_tuple() as part of
the second, such that HeapTupleSelfUpdated is seen as the
heap_lock_tuple() return value (within ExecOnConflictUpdate()). There
is no contradiction.

--
Peter Geoghegan