Re: Per tuple overhead, cmin, cmax, OID

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Per tuple overhead, cmin, cmax, OID
Date: 2002-06-07 21:14:31
Message-ID: 200206072114.g57LEVQ18078@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Manfred Koizar wrote:
> On Fri, 7 Jun 2002 02:01:40 -0400 (EDT), Bruce Momjian
> <pgman(at)candle(dot)pha(dot)pa(dot)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?

Oops, I see I added to TODO lately:

* Add version file format stamp to heap and other table types

Guess we would have to add it. Btree has it in nbtree.h:

uint32 btm_version;

I though heap should have it too. Of course, there are problems with
having the tuple read _know_ its version, and preventing mixing of
tuples of different versions in the same page.

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

Yep, only btree. I guess I didn't add it because it would cause
problems for pg_upgrade. :-)

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-06-07 21:52:39 Re: patch for contrib/intarray (7.2 and 7.3) (fwd)
Previous Message Manfred Koizar 2002-06-07 18:22:23 Re: Per tuple overhead, cmin, cmax, OID