Page type and version

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Page type and version
Date: 2002-07-05 23:38:05
Message-ID: hf8ciu8t87i46rn8shtkfufc5brk1re83m@4ax.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

As the upcoming release is breaking compatibility anyway: what do you
think about placing a magic number and some format version info into
the page header?

One 32-bit-number per page should be enough to encode page type and
version. We have just to decide, how we want it:

a) combine page type and version into a single 32-bit magic number

HEAPPAGE73 = 0x63c490c9
HEAPPAGE74 = 0x540beeb3
...
BTREE73 = 0x8cdc8edb
BTREE74 = 0xbb13f0a1

b) use n bits for the page type and the rest for a version number

HEAPPAGE73 = 0x63c40703
HEAPPAGE74 = 0x63c40704
...
BTREE73 = 0x8cdc0703
BTREE74 = 0x8cdc0704

The latter has the advantage, that the software could easily check for
a version range (e.g. if (PageGetVersion(page) <= 0x0703) ...).

One might argue, that one magic number *per file* should be
sufficient. That would mean, that the first page of a file had to
have a different format. Btree has such a meta page; I don't know
about the other access methods.

With a magic number in every single page it could even be possible to
do a smooth upgrade: "Just install Postgres 8.0 and continue to use
your PostgreSQL 7.4 databases" :-). Whenever the backend reads an old
format page it uses alternative accessor routines. New pages are
written in the new format. Or the database can be run in
compatibility mode ... I'm dreaming ...

Thoughts?

Servus
Manfred

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2002-07-06 00:53:32 Re: Proposal: CREATE CONVERSION
Previous Message Sander Steffann 2002-07-05 22:51:55 Re: Should next release by 8.0 (Was: Re: [GENERAL] I am