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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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