Re: Need advice for migration to pgsql
Enrique Zanardi <firstname.lastname@example.org> writes:
> On 13 Aug 1997, Siggy Brentrup wrote:
> > Before uploading a pgsql_v6.1.1 package, I need some advice how to
> > cope with a migration problem for users who have valuable data in a
> > previous postgres95 installation.
> > citing postgresql-v6.1.1/migration/1.09_to_6.0:
> > : This migration requires a complete dump of the 1.09 database and a
> > : restore of the database in 6.0.
> > : Those migrating from earlier 1.* releases should first upgrade to
> > : 1.09 because the COPY output format was improved from the 1.02
> > : release.
> > The postgres95 package in bo is version 1.09 - hence no intermediate
> > upgrade is required.
> > Then, the v6.1.1 INSTALL file instructs to use the pg_dumpall utility
> > from v6.1 up to backup an existing database.
> > Since pgsql replaces files from postgres95, the backup has to be run
> > before pgsql is unpacked or postgres95 is removed.
> > I'm thinking of a postgres95-migrate package where pgsql predepends
> > upon. Its postinst will check for postgres95 being installed and only
> > when this test succeeds prompt the user whether existing databases are
> > to be dumped. The postinst will only succeed when postgres95 is not
> > installed or existing databases have been successfully dumped.
> Why don't you run the backup in pgsql's preinst?
> If pgsql conflicts with postgres95, its preinst will be executed
> before unpacking pgsql, and before postgres95 is removed.
> (Debian packaging manual, v 18.104.22.168, section 6.3)
Sure, but the preinst runs *before unpacking*, when the pg_dumpall utility
from the new package is not yet available. Let me quote the relevant
portion from v6.1.1 INSTALL:
6) If you are upgrading an existing system then back up your database.
The database format is liable to change every few weeks with no
notice besides a quick comment in the HACKERS mailing list. It is
therefore a bad idea to skip this step. Also, do not use the
pg_dumpall script from v6.0 or everything will be owned by the
postgres super user. Type (with the gunzip line and the following
line typed as one line):
gunzip -c postgresql-v6.1.1.tar.gz |
tar xvf - src/bin/pg_dump/pg_dumpall
chmod a+x src/bin/pg_dump/pg_dumpall
src/bin/pg_dump/pg_dumpall > db.out
rm -rf src
If you wish to preserve object id's (oids), then use the -o
option when running pg_dumpall. However, unless you have a
special reason for doing this, don't do it.
Looking into the details, I don't see a clear upgrade path to cover
all possible cases.. I can't even assume the postgres95 postmaster is
running and postgres95 didn't provide a startup script in /etc/init.d
Taking into account a comment from Oliver Elphick <email@example.com> as
well as a private email from David R Baker <dabaker@InfoAve.Net> on
the same subject I will look into letting pgsql coexist with its
predecessor postgres95. This will necessitate changing the port on
wich the pgsql postmaster is listening as well as using different data
and library directories and diverting postgres95 executables that are
replaced by upgraded pgsql versions.
> Another comment, why is it called "pgsql"? Wouldn't it be less cryptic
> to use the long name "postgresql"?
Simply a matter of taste or call it sheer lazyness. While the original
source package is called postgresql, most other upstream references
use the short form pgsql. But if a majority nags for the full name,
>>> In a world without fences, who needs gates? <<<
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .