Skip site navigation (1) Skip section navigation (2)

Re: 7.2.3?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Justin Clift <justin(at)postgresql(dot)org>
Cc: Alvaro Herrera <alvherre(at)atentus(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.2.3?
Date: 2002-09-29 01:23:31
Message-ID: 200209290123.g8T1NVt03541@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Justin Clift wrote:
> Alvaro Herrera wrote:
> <snip>
> > I agree with Lamar that upgrading is a very difficult process right now.
> > Requiring huge amounts of disk space and database downtime to do
> > dump/restore is in some cases too high a price to pay.  So maybe the
> > upgrading process should be observed instead of wasting time on people
> > trying to stay behind because of the price of that process.
> 
> As a "simple for the user approach", would it be
> too-difficult-to-bother-with to add to the postmaster an ability to
> start up with the data files from the previous version, for it to
> recognise an old data format automatically, then for it to do the
> conversion process of the old data format to the new one before going
> any further?
> 
> Sounds like a pain to create initially, but nifty in the end.

Yes, we could, but if we are going to do that, we may as well just
automate the dump/reload.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

  • Re: 7.2.3? at 2002-09-28 21:30:35 from Justin Clift

Responses

  • Re: 7.2.3? at 2002-09-29 02:19:29 from Lamar Owen
  • Re: 7.2.3? at 2002-09-29 04:31:38 from Alvaro Herrera

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-09-29 01:47:59
Subject: Re: Improving backend startup interlock
Previous:From: Alvaro HerreraDate: 2002-09-29 00:06:04
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group