Re: Multiple postgresql packages proposed
On Thu, 2003-10-30 at 15:20, Anthony Towns wrote:
> On Wed, Oct 29, 2003 at 12:19:11AM +0000, Oliver Elphick wrote:
> > This is to get round problems with upgrading major versions, and to
> > allow people to have multiple database clusters, possibly at different
> > software versions.
>
> ] This is a major problem for Red Hat and Debian, because a dump and
> ] reload is not required by every upgrade and by the time the need for a
> ] dump is realised, the old software may be deleted. Debian has certain
> ] rather unreliable procedures to save the old software and use it to do
> ] a dump, but these procedures often go wrong.
>
> Maybe I'm just missing something obvious, but why don't you do a database
> dump on prerm upgrade, and a database restore on postinst configure? At
> prerm upgrade time you have the new package's version and the old
> package's binaries, so it shouldn't be a problem working out if you need
> to convert -- either go by major version number, or by encoding the db
> version as well -- or actually doing it. If the dump fails, you're in a
> great position to abort the upgrade too -- postgresql is still installed
> so you can just restart it, and let the admin work out wtf's going on
> while the old postgresql is still chugging away.
Suppose you have a multi-Gb database (PostgreSQL can support database
sizes in terabytes). Do you want to force a dump of that on every minor
release? There is no guarantee that there will even be enough disk
space. It will be a major problem for those who want to do unattended
package upgrades. And if anything does go wrong between upgrades, but
is not picked up till the postinst runs (which is more likely than a
failure during the dump), the old software is already gone. Can you
guarantee that the old binary package is still there to be reinstalled?
I've been over these problems many times over the past few years and I
consider the current proposal is likely to be more reliable than the
best I have previously managed to do -- and for database administrators
reliability is everything! Take a look at the bug list and see just how
many bugs relate to major version upgrade problems.
> Having multiple versions installed might be necessary for some weird
> sites, but all the extra complexity it involves is a good thing to avoid
> wherever possible.
It's not so weird.
If an ISP is supplying postgresql database facilities, and a new major
version comes along that changes the interface or syntax, as for example
the introduction of schemas with 7.3, many of his customers are going to
want to hold off implementing the new version until they have done their
testing, and they aren't likely to reach completion of testing all at
aonce. Many others will want to run development and production versions
side by side.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Bless the LORD, O my soul, and forget not all his
benefits: Who forgiveth all thine iniquities; who
healeth all thy diseases; Who redeemeth thy life from
destruction; who crowneth thee with lovingkindness and
tender mercies; Who satisfieth thy mouth with good
things; so that thy youth is renewed like the
eagle's." Psalms 103:2-5
Reply to: