>>> >> Problem is how to move tuple from page to another and keep indexes in sync.
>>> >> One solution is to perform some think like "update" operation on the tuple.
>>> >> But you need exclusive lock on the page and pin counter have to be zero. And
>>> >> question is where it is safe operation.
>>> >
>>> > But doesn't this problem go away if you do it in a transaction? You
>>> > set xmax on the old tuple, write the new tuple, and add index entries
>>> > just as you would for a normal update.
>>>
>>> But that doesn't actually solve the overflow problem on the old page...
>>
>> Sure it does. You move just enough tuples that you can convert the page
>> without an overflow.
>
> setting the xmax on a tuple doesn't "move" the tuple
Nobody said it did. I think this would have been more clear if you
had quoted my whole email instead of stopping in the middle:
>> But doesn't this problem go away if you do it in a transaction? You
>> set xmax on the old tuple, write the new tuple, and add index entries
>> just as you would for a normal update.
>>
>> When the old tuple is no longer visible to any transaction, you nuke it.
To spell this out in more detail:
Suppose page 123 is a V3 page containing 6 tuples A, B, C, D, E, and
F. We examine the page and determine that if we convert this to a V4
page, only five tuples will fit. So we need to get rid of one of the
tuples. We begin a transaction and choose F as the victim. Searching
the FSM, we discover that page 456 is a V4 page with available free
space. We pin and lock pages 123 and 456 just as if we were doing a
heap_update. We create F', the V4 version of F, and write it onto
page 456. We set xmax on the original F. We peform the corresponding
index updates and commit the transaction.
Time passes. Eventually F becomes dead. We reclaim the space
previously used by F, and page 123 now contains only 5 tuples. This
is exactly what we needed in order to convert page F to a V4 page, so
we do.
...Robert
