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

Andrew McMillan andrew@catalyst.net.nz
Sat, 21 May 2005 23:50:30 +1200 

--=-vx3Bns0I0i9pPfQ2EzoD
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2005-05-21 at 11:12 +0200, Martin Pitt wrote:
> >=20
> > Are the postgresql-7.4 packages in experimental supposed to be used, or
> > are they superseded by the postgresql-8.0 packages?  I was hoping to be
> > able to install this side-by-side with postgresql-8.0 and transition
> > across.
>=20
> 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.

Sure.  I understood that, but I was questioning whether the -7.4 was
supposed to actually (seamlessly) replace the existing postgresql.
Which it doesn't, because:
- the socket is in a different location.
- the database files don't get moved to the new location.

I think the first one is a bug, and someone has rightly filed a (grave)
bug against postgresql-8.0 for that reason.  Having the socket in /tmp
is just plain wrong, and while that might be fine for upstream, who have
to operate in a broad range of environments down-to-and-including
Windows, there are standards in Debian that strongly suggest /var/run is
the best place.

Given that here you are trying to implement an harmonious environment
for multiple different versions of postgresql, I can believe that
somewhere like /var/run/postgresql/7.4 would be a good place for that
socket, and that someone can then symlink from /var/run/postgresql to
whichever was currently preferred as 'default'.

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.

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.


> > So far I've managed to install postgresql-7.4, and to move my databases
> > across by just moving the files (base, global, pg_clog, pg_xlog) and
> > then applying various existing permissions and so forth
>=20
> 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.

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.  A dump and reload is a
right royal PITA, with multi-gigabyte databases. I desire a _simple_
transition path from postgresql(7.4.8) --> postgresql-7.4(7.4.8) so that
I _don't_ have to do a dump-and-reload step for this.  I realise that I
have to dump-and-reload to go to postgresql-8.0, but with the two
installed side-by-side this will be much easier.  Which is at least part
of the reason for all this in the first place.


> 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.

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.  Is this a case of
trying to cope with too many possibilities in an automated fashion?
Even without these new package structures I could (potentially) make
PostgreSQL run as any-old-user, and with the socket in any-old-place -
I'd have only had to write my own startup script.
Regarding bug #308597, I totally agree that /tmp is the wrong _default_
place.  On some systems old files in /tmp are deleted over a certain
age, and a long-running process could perhaps have it's socket removed!
The security implications are probably greater though, as Florian points
out: anyone can create files in /tmp and pretend to be the database
server, potentially sniffing passwords and such - particularly if they
used a hacked version of pgpool or something.


> > I've changed the /etc/postgresql/7.4/main/postgresql.conf file to
> > specify the socket location (so now my other applications are working
> > again), but that setting doesn't seem to be read by psql, and psql
> > doesn't appear to have options to use a socket other than what is
> > compiled in.
>=20
> That's why the packages are still in experimental; other packages
> dealing with PostgreSQL need to be recompiled anyway against libpq4,
> and they have to be adapted to the new paths. This was the major
> reason why the new packages did not go into Sarge.

Sure.  It gets my vote - I'm happy enough for 8.0 to not be in Sarge.
Very happy, in fact.

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?  And there's no way
to tell psql to use "this socket over here"...


> > Also, I was thinking of writing a script that would enable easy
> > transition from the existing postgresql (7.4.8) to postgresql-7.4
> > (7.4.8) by moving files around.  Would you be interested in such a
> > script, as an accessory to the package?
>=20
> It already exists. :-) The postgresql package in experimental (version
> 7.5.x) is a transition package which cares for that. So in the end,
> you just need to apt-get dist-upgrade and everything will be settled
> for you. :-)

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

Thanks,
					Andrew.

-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ  Ltd,  PO Box 11-053, Manners St,  Wellington
WEB: http://catalyst.net.nz/            PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201      MOB: +64(272)DEBIAN      OFFICE: +64(4)499-2267
Facts do not cease to exist because they are ignored. -- Aldous Huxley,
                         "Proper Studies", 1927

-------------------------------------------------------------------------


--=-vx3Bns0I0i9pPfQ2EzoD
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD8DBQBCjyCGjJA0f48GgBIRArrGAKDE26oa1IAMn3KNRGMe0uAcggEiwwCgyDS9
K2V3T65oFRui2hBw+7Q5lvY=
=LVcX
-----END PGP SIGNATURE-----

--=-vx3Bns0I0i9pPfQ2EzoD--