Re: 7.1 Release Date

Trond Eivind Glomsrød wrote:
> 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.

Oh, it's a very impractical idea from the standpoint of the glibc
version, the incompleteness of the system state mid-upgrade, etc.
However, from the point of view of the PostgreSQL dataset, it would be
nice to dump it BEFORE the old package is blown away, rather than deal
with the mess we have now...

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

Quoting Jeff Johnson:
Jeff Johnson wrote:
> The Red Hat install environment is a chroot. That means no daemons,
> no network, no devices, nothing. Even sniffing /proc can be problematic
> in certain cases.

ps, of course, uses /proc....

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

But condrestart doesn't exist in the old version....of course, the new
version initscript is in place by then....

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

And, IMHO, it is brain-dead to preclude user interaction when
interaction is necessary. Up until now, PostgreSQL upgrades have been
difficult to automate -- maybe that can be fixed by 7.1 (PostgreSQL
release).

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

> Prereq versions of the other components.

Well, it wasn't quite that simple with the RH 6.0-> 6.1 upgrade
(PostgreSQL 6.4.2-> PostgreSQL 6.5.2), as the number and names of the
packages themselves changed.

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

> More documentation is being worked on.

Good.

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

So would I, and many other folk, even those who are not using
prepackaged binary distributions. In fact, I just saw a message about
the upgrade procedure float by....

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11