[Pkg-postgresql-public] Re: postgresql-8.0 and postgresql-7.4 packages in experimental

[Martin Pitt]

--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Andrew!

Andrew McMillan [2005-05-21 23:50 +1200]:
> > That's in fact the reason why I developed postgresql-common and the
> > new architecture: to allow several major versions to be run in
> > parallel. So you can happily install 7.4 and 8.0 side by side.
>=20
> Sure.  I understood that, but I was questioning whether the -7.4 was
> supposed to actually (seamlessly) replace the existing postgresql.

No, you need the postgresql 7.5.x package for the transition. Without
such a transition package, the 7.4 package would become quite messy, I
want to avoid that. With a mere dist-upgrade you will get what you
want, so I think this should be sufficient.

> Which it doesn't, because:
> - the socket is in a different location.

I'll sort that out, see below.

> - the database files don't get moved to the new location.

That's done by postgresql 7.5.x.

> My real beef though, is that although I can tell the postgresql _server_
> where to put it's socket, I can't tell the psql client where to look for
> it.

You can, with the -h option. But that shouldn't be necessary normally.

> The second problem appears to be due to versions of dependencies,
> meaning that the "postgresql" package was uninstalled when I installed
> "postgresql-7.4" on my system.

Right, because they conflict to each other. That's intended.

> > You need to dump the 7.4 database and reload it into an 8.0 database.
> > That's what the pg_upgradecluster tool is for (see manpage). The next
> > version of postgresql-common will ship a README.Debian with some
> > introduction.
>=20
> Well, no, it seems I _didn't_ need to do this.  Stopping the database
> server and doing the binary copy of the files worked just fine, given
> that it was PostgreSQL 7.4.8 in both cases.

Sorry, my fault. I thought you wanted to upgrade to 8.0. Of course you
don't need a dump in this case.

> > Actually it is supposed to be this way, and in the new architecture
> > all client programs expect the socket in /tmp (which is upstream's
> > default). However, some people seem to like the old location [1]. I
> > did not yet follow up to this bug, will do ASAP. It's not that trivial
> > to put sockets into /var/run/postgresql since only the 'postgres' user
> > can write into this. However, a cluster can be owned by an arbitrary
> > Unix system user (on purpose). I still need to think about that.
>=20
> The postgresql.conf file can specify where the file should go, so if
> someone is trying to run the database server as !postgres then perhaps
> they should control their own destiny even further. =20

Right, that's the approach I will follow. For postgres, the socket is
put into /var/run/postgresql/ (as before), for other users it will
default to /tmp and pg_createcluster will write a message which
suggests to change it.

> Is this a case of trying to cope with too many possibilities in an
> automated fashion?

> Should I file a bug though, in that if I set the socket to be in a
> non-default location via the postgresql.conf file, psql doesn't use that
> information and so then fails to find any databases? =20

Good point, I added it to the TODO list. No need for a bug (but feel
free to file one if you want to track its status :-) ).

> And there's no way to tell psql to use "this socket over here"...

psql -h /your/path/to/socket/

> Hmmm.  I saw the postgresql-7.4 and friends and installed them and in
> the process 'postgresql' was removed due to some sort of conflicts
> (libpq3 version dependencies?) so I guess I never had the opportunity to
> see the automated upgrade :-(

What a pity, it should work pretty well.. :-)

Thanks for your thoughts and have a nice day!

Martin
--=20
Martin Pitt                 Debian GNU/Linux Developer
martin@piware.de                      mpitt@debian.org
http://www.piware.de             http://www.debian.org

--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCkIDBDecnbV4Fd/IRArR8AJ4p48mAwqMLj9VVAcvO0Pd/iV0vrwCghn6N
ybreRjLzeFOzzgqtbAaho2c=
=2PEJ
-----END PGP SIGNATURE-----

--mP3DRpeJDSE+ciuQ--