[Pkg-postgresql-public] pg_upgrade support in pg_upgradecluster

[Martin Pitt]

Peter Eisentraut [2012-07-25 15:12 +0300]:
> I wouldn't remove the dump mode altogether yet.

No, neither would I, I'd just chose the pg_upgrade method as internal
implementation detail if/when it is available.

> > > -print "Restarting old cluster with restricted connections...\n";
> > > - at argv = ('pg_ctlcluster', $version, $cluster, 'start');
> > > -error "Could not restart old cluster" if system @argv;
> > > +if ($method eq 'dump') {
> > > +    print "Restarting old cluster with restricted connections...\n";
> > > +    @argv = ('pg_ctlcluster', $version, $cluster, 'start');
> > > +    error "Could not restart old cluster" if system @argv;
> > > +}
> > 
> > Is there no danger of accessing the cluster while it's being upgraded
> > with pg_upgrade?
> 
> The main point is that the cluster must be down before running
> pg_upgrade.

Oh, right.

> The conditional above just takes out the restarting; the disabling
> of connections still happens, although it's probably useless.

Agreed, this can be skipped as well then.

> Come to think of it, I like putting it into /var/log/postgresql and just
> leaving it there, as a kind of log output.  Because there could be
> things in there that you might want to look at even if successful.
> 
> But in terms of predictable file names, what do you suggest to do if
> someone runs the same upgrade several times, e.g., after failed
> attempts?

I wouldn't consider them that precious; as the new cluster is either
automatically deleted (on failure) or manually deleted before
re-upgrading (if you aren't satisfied), there is little point in
keeping old upgrade logs around IMHO. If you think there is, I'd
rather append a date/time suffix than a nonce.

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)