Heikki Linnakangas <heikki@enterprisedb.com> writes:
> There is one wacky idea I haven't dared to propose yet:
> We could lift the limitation that you can't defragment a page that's
> pinned, if we play some smoke and mirrors in the buffer manager. When
> you prune a page, make a *copy* of the page you're pruning, and keep
> both versions in the buffer cache. Old pointers keep pointing to the old
> version. Any new calls to ReadBuffer will return the new copy, and the
> old copy can be dropped when its pin count drops to zero.
No, that's way too wacky. How do you prevent people from making further
changes to the "old" version? For instance, marking a tuple deleted?
The actual practical application we have, I think, would only require
being able to defrag a page that our own backend has pins on, which is
something that might be more workable --- but it still seems awfully
fragile. It could maybe be made to work in the simplest case of a
plain UPDATE, because in practice I think the executor will never
reference the old tuple's contents after heap_update() returns. But
this falls down in more complex situations involving joins --- we might
continue to try to join the same "old" tuple to other rows, and then any
pass-by-reference Datums we are using are corrupt if the tuple got
moved.
regards, tom lane