Re: [WIP] In-place upgrade

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] In-place upgrade
Date: 2008-11-05 04:51:32
Message-ID: 603c8f070811042051t6c2a7d63j97f83aa367794e47@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> No, that's not what I'm suggesting. My thought was that any V3 page
>> would be treated as if it were completely full, with the exception of
>> a completely empty page which can be reinitialized as a V4 page. So
>> you would never add any tuples to a V3 page, but you would need to
>> update xmax, hint bits, etc. Eventually when all the tuples were dead
>> you could reuse the page.
>
> But there's no guarantee that will ever happen. Heikki claimed you would need
> a mechanism to convert the page some day and you said you proposed a system
> where that wasn't true.

What's the scenario you're concerned about? An old snapshot that
never goes away?

Can we lock the old and new pages, move the tuple to a V4 page, and
update index entries without changing xmin/xmax?

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2008-11-05 05:02:11 Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle
Previous Message Hitoshi Harada 2008-11-05 04:47:22 Re: Windowing Function Patch Review -> Standard Conformance