On Tue, Dec 1, 2009 at 10:34 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> > Well, there were quite a number of open issues relating to page
>> > conversion:
>> >
>> > ? ? ? ?o ?Do we write the old version or just convert on read?
>> > ? ? ? ?o ?How do we write pages that get larger on conversion to the
>> > ? ? ? ? ? new format?
>> >
>> > As I rember the patch allowed read/wite of old versions, which greatly
>> > increased its code impact.
>>
>> Oh, for sure there were plenty of issues with the patch, starting with
>> the fact that the way it was set up led to unacceptable performance
>> and code complexity trade-offs.  Some of my comments from the time:
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-11/msg00149.php
>> http://archives.postgresql.org/pgsql-hackers/2008-11/msg00152.php
>>
>> But the point is that the concept, I think, is basically the right
>> one: you have to be able to read and make sense of the contents of old
>> page versions.  There is room, at least in my book, for debate about
>> which operations we should support on old pages.  Totally read only?
>> Set hit bits?  Kill old tuples?  Add new tuples?
>
> I think part of the problem is there was no agreement before the patch
> was coded and submitted, and there didn't seem to be much desire from
> the patch author to adjust it, nor demand from the community because we
> didn't need it yet.

Could be.  It's water under the bridge at this point.

>> The key issue, as I think Heikki identified at the time, is to figure
>> out how you're eventually going to get rid of the old pages.  He
>> proposed running a pre-upgrade utility on each page to reserve the
>> right amount of free space.
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-11/msg00208.php
>
> Right.  There were two basic approaches to handling a patch that would
> expand when upgraded to the new version --- either allow the system to
> write the old format, or have a pre-upgrade script that moved tuples so
> there was guaranteed enough free space in every page for the new format.
> I think we agreed that the later was better than the former, and it was
> easy because we don't have any need for that at this time.  Plus the
> script would not rewrite every page, just certain pages that required
> it.

While I'm always willing to be proven wrong, I think it's a complete
dead-end to believe that it's going to be easier to reserve space for
page expansion using the upgrade-from version rather than the
upgrade-to version.  I am firmly of the belief that the NEW pg version
must be able to operate on an unmodified heap migrated from the OLD pg
version.  After this set of patches was rejected, Zdenek actually
proposed an alternate patch that would have allowed space reservation,
and it was rejected precisely because there was no clear certainty
that it would solve any hypothetical future problem.

...Robert

In response to

• Re: Page-level version upgrade (was: Block-level CRC checks) at 2009-12-02 03:34:11 from Bruce Momjian

Responses

• Re: Page-level version upgrade (was: Block-level CRC checks) at 2009-12-02 04:45:18 from Bruce Momjian

pgsql-hackers by date

Next:	From: Robert Haas	Date: 2009-12-02 04:17:58
	Subject: Re: Page-level version upgrade (was: Block-level CRC checks)
Previous:	From: Joshua Tolley	Date: 2009-12-02 03:53:49
	Subject: Re: PL/Python array support