| 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: | Whole Thread | Raw Message | 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 |