[CentOS-devel] Upgrading postgresql (Re: CentOS/RHEL 5.3)

Fri Jan 23 01:26:36 UTC 2009
John Summerfield <debian at herakles.homelinux.org>

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:-)