Robert Haas <robertmhaas@gmail.com> writes:
> Brainstorming wildly, how about something like this:
> 1. Insert a new copy of the tuple onto some other heap page. The new
> tuple's xmin will be that of the process doing the tuple move, and
> we'll also set a flag indicating that a move is in progress.
> 2. Set a flag on the old tuple, indicating that a tuple move is in
> progress. Set its TID to the new location of the tuple. Set xmax to
> the tuple mover's XID. Optionally, truncate away the old tuple data,
> leaving just the tuple header.
> 3. Scan all indexes and replace any references to the old tuple's TID
> with references to the new tuple's TID.
> 4. Commit.
What happens when you crash partway through that? Also, what happens if
somebody wishes to update the tuple before the last step is complete?
In any case, this doesn't address the fundamental problem with unlocked
tuple movement, which is that you can't just arbitrarily change a
tuple's TID when there might be other operations relying on the TID
to hold still.
regards, tom lane
