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
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. |