From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Eric Sproul <esproul(at)omniti(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 8.1 beta1 -> beta2 upgrade question |
Date: | 2005-10-12 22:03:13 |
Message-ID: | 4547.1129154593@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> There has been talk in the past about creating a tool for in-place
> upgrades. The most complete description of the needed work I've seen
> posted to date is here:
> http://archives.postgresql.org/pgsql-hackers/2003-12/msg00379.php
> There was another proposal after that,
> http://archives.postgresql.org/pgsql-hackers/2004-09/msg00916.php
> Neither of them yielded any useful software, that I know of.
Yeah, I'm afraid I got distracted and never got very far on the first
scheme. It still seems perfectly workable, within the limited goals it
has --- in particular, it doesn't support changes in the on-disk format
of user tables; hence no tuple-header-layout changes or datatype
redesigns. But it would work for 99% of the changes we make, and
certainly for all cases that seem plausible to happen during beta
cycles.
I think the second one isn't worth the electrons it's written on,
because the smgr API is at far too low a level of abstraction to be
able to solve the problem :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-10-12 22:14:00 | Re: Comments on columns in the pg_catalog tables/views |
Previous Message | Eric Sproul | 2005-10-12 21:40:00 | Re: 8.1 beta1 -> beta2 upgrade question |