From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)tm(dot)ee> |
Cc: | mlw <pgsql(at)mohawksoft(dot)com>, Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Upgrading rant. |
Date: | 2003-01-03 20:37:56 |
Message-ID: | 11163.1041626276@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> I don't think the main issues are with file _formats_ but rather with
> system file structures - AFAIK it is a fundamental design decision
> (arguably a design flaw ;( ) that we use system tables straight from
> page cache via C structure pointers,
The system tables are not the problem. pg_upgrade has shown how we
can have cross-version upgrades no matter how much the system catalogs
change (a good thing too, because we cannot freeze the system catalog
layout without bringing development to a standstill). A schema-only
dump and restore is cheap enough that there's no real reason to look
for any other solution.
Changes in the on-disk representation of user tables would be harder to
deal with, but they are also much rarer (AFAIR we've only done that
twice: WAL required additions to page and tuple headers, and then there
were Manfred's space-saving changes in 7.3). And as of 7.3 there is a
version field in page headers, which would in theory allow for a
page-at-a-time update process to work.
There isn't any fundamental reason why we cannot have a pg_upgrade
utility; claiming that there is something wrong with how we handle
catalog changes misses the point. The point is that *someone would
have to do the work*. Unless someone wants to step up and volunteer,
there's little value in discussing it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2003-01-03 20:47:22 | Re: Threads |
Previous Message | Tom Lane | 2003-01-03 20:24:32 | Re: python interface |