| From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
| Subject: | Re: pg_upgrade (was: 8.2 features status) |
| Date: | 2006-08-04 19:30:31 |
| Message-ID: | 20060804193031.GP40481@pervasive.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Aug 04, 2006 at 02:12:16PM -0400, Stephen Frost wrote:
> * Jim C. Nasby (jnasby(at)pervasive(dot)com) wrote:
> > On Thu, Aug 03, 2006 at 11:20:48PM -0700, Josh Berkus wrote:
> > > > * In-place upgrades (pg_upgrade)
> > >
> > > BTW, I may get Sun to contribute an engineer for this; will get you posted.
> >
> > How would such a thing handle changes to page formats?
>
> Couldn't this be done by converting a table/partial-table at a time?
> It wouldn't be something which could run while the system is live, but
> it'd probably take less time than dump/restore and wouldn't require
> double the disk space of the whole database... no?
True, but if you're going to go about creating code that can deal with 2
different versions of on-disk data, why not go one better: put that code
into the database itself, so that pages are converted on-the-fly as
they're dirtied. That way you have *no* downtime (or almost no, anyway).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-08-04 19:32:12 | Re: 8.2 features status |
| Previous Message | Jim C. Nasby | 2006-08-04 19:28:11 | Re: 8.2 features status |