Maxim Boguk <maxim.boguk@gmail.com> writes:
> I tracked virtual tuple from heaptuple.c::slot_getattr down to
> execMain.c::ExecUpdate and I think somewhere in this way virtual tuple
> should be need to be "materialized" into physical tuple.
That happens at the top of ExecUpdate:
/*
* get the heap tuple out of the tuple table slot, making sure we have a
* writable copy
*/
tuple = ExecMaterializeSlot(slot);
I don't see any code path there that could re-virtualize the slot.
Do you have any triggers or constraints on the target table? Because
those are about the only things that influence this code path at all...
> Again I not sure but ExecProcessReturning function seems good candidate to
> perform tuple materialization.
If ExecProcessReturning were given a virtual slot, materializing it
would do no good at all for this problem, because the system columns in
the result would be garbage. It has to receive an already materialized
slot that contains the right information beforehand. The only reason
that retrieving ctid can work at all is that when heap_update is called,
"tuple" is pointing at the slot's contained tuple and so setting
tuple->t_self changes the contents of the slot. That whole function is
completely dependent on the slot contents being physical not virtual,
and I don't see anything there that would break it.
regards, tom lane
