Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I figured out that the cases where setheapoverride (or, now,
>> CommandCounterIncrement) were needed were the cases where the
>> heap_update might be updating a tuple created earlier in the
>> same command. pg_operator.c has some cases like that, but many of
>> the other uses of setheapoverride seem to be unnecessary.
> I thought about that this morning and suspected this may be the case,
> though I thought tuples would be visible to the same transaction
> automatically. Hard to imagine why we would not want such visibility in
> all cases.
Normally you *don't* want tuples created/updated in the current command
to be visible. Consider an UPDATE proceeding by sequential scan. As it
finds tuples it needs to update, the updated versions of those tuples
will get added to the end of the relation. Eventually the UPDATE will
reach those tuples and be scanning its own output! Thanks to the
visibility rule, it will ignore those new tuples as not-yet-visible.
Without that, something as simple as "UPDATE t SET f = f + 1" would be
an infinite loop.
CommandCounterIncrement() is like a statement boundary inside a
transaction: after you call it, you can see the effects of your
prior operation (but no one else can; it's not a commit).
regards, tom lane