Re: Pains in upgrading to 8.3

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, Tony Caduto <tony_caduto(at)amsoftwaredesign(dot)com>, paul rivers <rivers(dot)paul(at)gmail(dot)com>, Postgres General List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Pains in upgrading to 8.3
Date: 2008-02-16 23:19:35
Message-ID: 200802162319.m1GNJZP15464@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Magnus Hagander wrote:
> Dave Page wrote:
> > On Fri, Feb 15, 2008 at 4:21 PM, Tony Caduto
> > <tony_caduto(at)amsoftwaredesign(dot)com> wrote:
> >> paul rivers wrote:
> >> >>
> >> > Going from 8.2.4 and 8.2.6 to 8.3.0 has been painless for me.
> >> > However, unlike the blogger you cite, I read the directions before,
> >> > not after, attempting it.
> >>
> >>
> >> The blogger has a point about pg_dump and restore, it could be much
> >> better, for example
> >> the backup process could be part of the server core and instead of
> >> having a fat client where most of the process is running on the client,
> >> a API could be
> >> used where the backup is generated on the server and then have options
> >> where it could be left on the server or transferred to the clients PC.
> >
> > Not really an option - the reason it's recommended to use the new
> > pg_dump version with the older server when upgrading is to allow the
> > dump to be made in the way most compatible with the new server,
> > effectively doing some of the upgrade process as part of the dump
> > operation.
>
> For the case of upgrading, it wouldn't work. But there are certainly
> other cases where it would help. Say from your central pgadmin console
> administering 10 servers from 3 different major release trees :-(
>
> It can be done with commandline pg_dump, but it means you have to have
> three different installs on your management or backup or whatever
> machine. Those cases would certainly be easier if you could just call a
> backup API on the server that would feed you the data... (yes, there are
> ways to do it with ssh tunneling and whatever, but that's yet another
> external service that has to be set up and configured)

Using the new pg_dump for dumping older versions during an ugprade is
just inconvenient and something we should not need to do. At the worst
we should have a way for us to upgrade the older version of pg_dump with
whatever functionality we need and just tell people to be running the
most recent minor release before upgrading.

What cases on the past have needed the new pg_dump?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2008-02-16 23:29:36 Re: Query output into a space delimited/location sensitive file
Previous Message Stephan Szabo 2008-02-16 21:17:51 Re: SELECT CAST(123 AS char) -> 1