[Dbconfig-common-devel] dbconfig-common/doc dbapp-policy.html,1.5,1.6 dbconfig-common-design.html,1.4,1.5 dbconfig-common-using.html,1.5,1.6 dbconfig-common.html,1.5,1.6

[sean finney]

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

hi karsten,

On Fri, Mar 04, 2005 at 05:05:42PM +0100, Karsten Hilbert wrote:
> >  <p>
> > -before a package is upgraded, it should make a backup of any database
> > -in the case of error.
> This is very prudent.

yeah, that's what i was thinking :).

> >  the backup should be performed early, ahead of
> > -the new package being unpacked.  this ensures that the versions of the
> > -software necessary to interact with the previous version of the databa=
se
> > -are present, since newer versions of the tools might not necessarily
> > -be compatible.
> In PostgreSQL the recommended procedure is to use the pg_dump
> of the *newer* version, however.

> Taken together this probably means that one should
>=20
> a) make a backup with the old version before changing anything
>    just to be on the safe side
> b) make a second backup intended for restoring into the new
>    database version as soon as the new dump utility is
>    available

hmm.. i might have to defer to someone who knows the idiosynchrasies of
postgres better than myself on this.  is there anything that would be
different in the SQL between versions?  my approach thusfar was to
avoid the binary dump formats of mysql/pgsql in favor of the plain old SQL=
=20
format to try and circumvent such problems.


glad to see there are still folks interested in this :)

	sean

--=20

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

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

iD8DBQFCKOsPynjLPm522B0RAknCAJ9XXrjdSVQwnzjs8c8Cqug5+j79CQCeLPfG
HiNvyM7Pbjhm003qP9h/CGo=
=0fC9
-----END PGP SIGNATURE-----

--KFztAG8eRSV9hGtP--