[Pkg-postgresql-private] System for managing multiple postmasters?

Martin Pitt martin@piware.de
Wed, 15 Oct 2003 15:04:13 +0200


--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

On 2003-10-13 18:38 +0100, Oliver Elphick wrote:
> Your suggestion of parallel installations is the solution I have been
> considering.  If the new package could be installed alongside the old,
> there would be no need to upgrade the data during installation and no
> danger of data loss.

I thought a bit about that. I think those two concepts (should) have
nothing to do with each other.

Having installed multiple versions of psql in parallel (i. e. 7.3.x
and 7.4.x, not necessarily different point releases from the same 7.3)
may be interesting for some users. I don't see a principle technical
obstacle against it although I did not dig into the guts of psql to
decide whether this would actually possible by now.

OTOH, there must still be the possibility of upgrading, otherwise I am
forced to have 20 database versions installed in parallel after some
time.  As far as I understand your proposal, you want to shift the
migration responsibility from the Debian package scripts to the user
(DB administrator). Thus, as an user, if I would really be interested
in upgrading and I am told that the provided update programs (which
convert the database on the binary level) is fragile and apt to mess
up everything, what would I do?=20

I would pg_dumpall my current db, purge everything, install the new
psql version and feed back the dump. As a migration strategy on SQL
level (as opposed to binary), this method would take much longer, but
is certainly far more robust. So if binary updating isn't possible or
reliable, then why we don't just offer an automated way of doing this
source-level conversion? If the automatic upgrade fails, the DB admin
still has the SQL dump and can feed it manually or reinstall the old
version, thus data loss should not occur.

IMHO a major database upgrade should not be made in a critical running
system anyway, so I think we shouldn't put too much effort in
minimizing downtime when the price for it is loss of robustness.

I appreciate any comments!

Thanks and have a nice day!

Martin
--=20
Martin Pitt
home:  www.piware.de
eMail: martin@piware.de

--/9DWx/yDrRhgMJTb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQE/jUXKDecnbV4Fd/IRAoDGAJwKTsJQ2UzsB43cQh0MZB/LaOI1EACfRz5z
R6NxGY7sdG5GxzyJgockLt8=
=GqN/
-----END PGP SIGNATURE-----

--/9DWx/yDrRhgMJTb--