Re: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0]

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, jbj(at)redhat(dot)com, lockhart(at)alumni(dot)caltech(dot)edu
Subject: Re: [Fwd: [HACKERS] Re: Postgresql 6.5-1 rpms on RedHat 6.0]
Date: 1999-07-08 18:30:33
Message-ID: 3784EE49.697C70FD@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> There are several other bugfixes over 6.5 in the RPM already, so I
> see no good reason not to just remove those four symlinks; it certainly
> seems cleaner than kluging the RPM script...

> regards, tom lane

Yes, that's quite true.

Speaking of the rpms, I have just found a few issues that my other
testing had not found. Specifically:
* The data necessary to initdb is in postgresql-devel, not
postgresql-server (the files in /usr/lib/pgsql, specifically the bki
sources);
* There are no static libraries in postgresql-devel (libpq.a, et al --
these are normally located in /usr/lib)
* IMHO, a warning should be printed about proper updgrade procedure --
rpm -U just simply won't work as the rpms (and postgresql) are currently
implemented -- and, unfortunately, the rpm -Uvh style is the default
method for most users, as well as RedHat version updates, from 5.2 to
6.0, for example.

As far as enhancements go, the postgresql-server rpm could (not
necessarily should) check to see if a database structure exists in
/var/lib/pgsql (if so, move it out of the way), and perform an initdb.

Where this comes into play is when upgrading postgresql versions using
rpm -- the rpm uninstall does not blow away the whole PGDATA/base tree
-- in fact, it leaves _everything_ there. So, to upgrade, you must
either rm -rf the tree or mv it out of the way -- preferably before
doing an initdb.

What IS the right way to do this in an automated fashion? Currently, to
upgrade via rpm (on a box running SysV init, such as RedHat), you must
do the following:

1.) as postgres, pg_dumpall
2.) as postgres, backup pg_hba.conf
3.) as root, rpm -e all-old-postgresql-rpms (found using rpm -qa|grep
postgres) (automateable -- rpm -qa|grep postgresql|xargs rpm -e (check
that xargs syntax...))
4.) as root, blow away the /var/lib/pgsql tree, taking care not to blow
away your backup
5.) as root, rpm -i select-new-postgresql-rpms
6.) as postgres, initdb --pglib=/usr/lib/pgsql --pgdata=/var/lib/pgsql
7.) as root, Edit /etc/rc.d/init.d/postgresql as needed (to add -i, FE)
(to automate this, simply include -i by default, or give user a choice,
and sed away...)
8.) as root, start postmaster (/etc/rc.d/init.d/postgresql start)
9.) as postgres, psql -e template1 < pg_dumpall-backup-from-step-1
10.) as postgres, restore pg_hba.conf
11.) Restart production tasks, after testing.

Have I left anything out? Is it even desireable to automate this? (In my
case, I'm going to build a script to keep around to do this...)

Lamar Owen
WGCR Internet Radio

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rantapaa 1999-07-08 18:34:12 6.3 spurious transaction aborted problem
Previous Message Jan Wieck 1999-07-08 18:14:02 Re: [HACKERS] Arbitrary tuple size