Re: [WIP] In-place upgrade

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>, "Greg Stark" <greg(dot)stark(at)enterprisedb(dot)com>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] In-place upgrade
Date: 2008-11-06 03:12:20
Message-ID: 603c8f070811051912w16827461q9bf5576eb814e885@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> >> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2008-11-06 03:31:40 Re: BufferAccessStrategy for bulk insert
Previous Message Joshua Tolley 2008-11-06 03:11:19 Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets