Re: Per tuple overhead, cmin, cmax, OID - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: Per tuple overhead, cmin, cmax, OID
Date
Msg-id fbk1gu41u08796i524upsh4a5f65m9foo6@4ax.com
Whole thread Raw
In response to Re: Per tuple overhead, cmin, cmax, OID  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Per tuple overhead, cmin, cmax, OID  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Fri, 7 Jun 2002 02:01:40 -0400 (EDT), Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
>I think it is inevitable that there be enough binary file changes the
>pg_upgrade will not work for 7.3 --- it just seems it is only a matter
>of time.

As far as it concerns changes proposed by me, I'll (try to) provide a
conversion program, if that's necessary for my patches to be accepted.
Then move_objfiles() in pg_update would have to call pg_convert, or
whatever we call it, instead of mv.  And yes, users would need twice
the disk space during pg_upgrade.

>One idea is to allow alternate page layouts using the heap page version
>number, but that will be difficult/confusing in the code.

This is a good idea, IMHO.  By saying "*the* heap page version number"
do you mean, that there already is such a number by now?  I could not
find one in bufpage.h.  Should I have looked somewhere else?

While we're at it, does each file start with a magic number
identifying its type?  AFAICS nbtree does; but I can't tell for heap
and have not yet checked for rtree, gist, ...  This is the reason for
the "try to" in the first paragraph.

ServusManfred


pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: Use of /etc/services?
Next
From: Bruce Momjian
Date:
Subject: Re: Per tuple overhead, cmin, cmax, OID