I wrote:
> I think EvalPlanQual is deciding that updated tuples are valid in
> some cases where it shouldn't. Unfortunately, if that's correct it
> means that all the branches are broken since last August :-(
OK, here's the deal: the former coding of EvalPlanQual ignored (returned
NULL for) any tuple that was determined to have been updated by the
current transaction. This is clearly wrong --- tuples updated by
previous commands of the current transaction should be visible for
further modification. However, the new coding is also wrong --- tuples
already updated by the current command of the current transaction should
be ignored, and they aren't being. The reason Euler's query is failing
is that there are multiple "itensmov" rows joining to some rows of
"produtos", leading to multiple attempts to update the row.
(BTW, this raises the question whether his query is really correct or
not, but I think we need to restore the previous behavior where the
first update attempt succeeds and additional updates in the same command
are just dropped. This is what happens when EvalPlanQual is not entered
because there are no concurrent transactions, so we want to make the
concurrent case work the same.)
It looks to me like the correct test requires passing in the current
command ID so we can check the tuple's cmax against it.
regards, tom lane