Maxim Boguk <maxim.bo...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs