Re: 7.1 Release Date

From: teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: 7.1 Release Date
Date: 2000-08-29 20:13:07
Message-ID: xuypumrvnak.fsf@hoser.devel.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:

> 'Brain-dead' meaning WRT upgrading RPMs...:
> 1.) I can't start a backend to dump data if the RPM is installing under
> anaconda;

You can try, but I don't see it as a good idea.

> 2.) I can't check to see if a backend is running (as an RPM pre or post
> script can't use ps or cat /proc reliably (according to Jeff Johnson) if
> that pre or post script is running under anaconda);

This should work, I think.

> 3.) I can't even check to see if the RPM is installing under anaconda!

That should be irrelavant, actually - RPM is designed to be
non-interactive. The best place to do this would probably be in the
condrestart, which is usually run when upgrading and restarts the
server if it is already running.

> (ie, to have a more interactive upgrade if the RPM -U is from the
> command line, a check for the dump, or a confirmation from the user that
> he/she knows what they're getting ready to do)

rpm is non-interactive by design.

> 4.) I'm not guaranteed of package upgrade order with split packages;

Prereq versions of the other components.

> 5.) I'm not even guaranteed to have basic system commands available,
> unless I Prereq: them in the RPM (which is the fix for that);

Yup.

> 6.) The installation chroot system is flakey (again, according to Jeff
> Johnson) -- the least things you do, the better.

No. Yes.

> 7.) The requirements and script orders are not as well documented as one
> might want.

More documentation is being worked on.
>
> Upgrades should just be this simple:
> Install new version.
> Start new version's postmaster, which issues a 'pg_upgrade' in safest
> mode.
> If pg_upgrade fails for any reason, get DBA intervention, otherwise,
> just start the postmaster already!

I would love that.

--
Trond Eivind Glomsrød
Red Hat, Inc.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adam Lang 2000-08-29 20:33:04 Shutting down pgsql
Previous Message Andrew Sullivan 2000-08-29 20:09:31 Re: 7.1 Release Date