[CentOS-devel] Upgrading postgresql (Re: CentOS/RHEL 5.3)
John Summerfield
debian at herakles.homelinux.org
Fri Jan 23 01:26:36 UTC 2009
Jeff Johnson wrote:
>
> On Jan 22, 2009, at 4:40 PM, Les Mikesell wrote:
>>
>> Agreed, it doesn't work. Nor does any other RPM-managed update where
>> you need to have both old and new packages simultaneously working for a
>> while. The special case for the kernel is about the only place where it
>> even attempts to keep old versions around for an emergency fallback.
>>
>
> Honking about RPM deficiencies on a CentOS Devel list is hot air going
> no place.
>
> FWIW, there's no package system that provides sufficient facilties to
> undertake
> a postgres upgrade reliably during upgrade that I'm aware of. Nor is it
> "recommended" afaik.
I thought that point was already conceded.
However, there is nothing now that prevents two versions of postgresql
from being built with version-dependent directory names (as it almost is):
[root at numbat ~]# rpm -qvl postgresql | grep ^d
drwxr-xr-x 2 root root 0 Jan 12 2008 /usr/lib/pgsql
drwxr-xr-x 2 root root 0 Jan 12 2008
/usr/share/doc/postgresql-8.1.11
drwxr-xr-x 2 root root 0 Jan 12 2008
/usr/share/doc/postgresql-8.1.11/html
[root at numbat ~]#
Change that to /usr/lib/pgsql-8.1.11, create a bin directory in there
and use the alternatives system to choose the default.
The configuration and data directory names need to be changed too.
>
> But supply a pointer to your favorite package manager that _DOES_ attempt
> postgres database upgrades and I'll be happy to attempt equivalent in RPM.
>
> Personally, I think that database upgrades have almost nothing
> to do with instaling packages, but I'd rather add whatever is useful
> than discuss well known RPM deficiencies for another decade.
In-package (or upgrade-time) configuration conversion will always fail
for some packages, but I see no reason that users shouldn't be able to
run old and new versions of (at least) _some_ packages simultaneously.
It would make upgrades easier for sysadmins with just a few systems to
maintain - depending on needs they could upgrade a clone and test it and
fix and document broken bits without having to start from scratch each time.
--
Cheers
John
-- spambait
1aaaaaaa at coco.merseine.nu Z1aaaaaaa at coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
More information about the CentOS-devel
mailing list