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

Re: Upgrading rant.

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Hannu Krosing <hannu(at)tm(dot)ee>, mlw <pgsql(at)mohawksoft(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Upgrading rant.
Date: 2003-01-06 04:04:59
Message-ID: 200301052304.59936.lamar.owen@wgcr.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Saturday 04 January 2003 21:12, Peter Eisentraut wrote:
> I would recommend requiring users to do the schema dump before upgrading
> the binaries, so they'd do

Nice theory.  Won't work in RPM practice.  I can't require the user to do 
_anything_.  Due to the rules of RPM's, I can't even ask the user to do 
anything.  All I have been able to do is prevent the upgrade from happening 
-- but that has its cost, too, as then older library versions have to be held 
back just for PostgreSQL, taking up the hapless user's disk space.

While I _can_ version the binaries as Tom mentioned (and that I had thought 
about before), in an OS upgrade environment (where my RPMset lives more than 
by command line rpm invocation) I can't force the older set to be kept in a 
runnable form.  It is very possible that the supporting libc shared libraries 
will be removed by the OS upgrade -- the old binaries may not even run when 
it is critical that they do run.

In place post-binary-upgrade is the only way this is going to work properly in 
the environment I have to live with.  That's why dump/restore is such a pain, 
as Tom remembers.

If I can get older versions building again on newer systems, that will help 
buy some breathing room from my point of view.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2003-01-06 04:10:08
Subject: Re: Upgrading rant.
Previous:From: Tom LaneDate: 2003-01-06 03:56:13
Subject: Re: Upgrading rant.

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