On tor, 2011-09-01 at 18:55 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > +# contrib/pg_upgrade/test.sh
> > > +#
> > > +# Test driver for pg_upgrade.  Initializes a new database cluster,
> > > +# runs the regression tests (to put in some data), runs pg_dumpall,
> > > +# runs pg_upgrade, runs pg_dumpall again, compares the dumps.
> > 
> > Hm .. my experience is that that doesn't work at all, because the
> > regression tests set up assorted C functions whose implementations are
> > in pg_regress.so, and it creates them with absolute path references
> > to pg_regress.so.  When you try to load that into another installation
> > that's a different version of PG, it quite properly fails.  So I think
> > that as given, this script is only useful for testing pg_upgrade of
> > $currentversion to $currentversion.  Which is surely better than no test
> 
> Reminder --- you can't use pg_upgrade to go from the same catalog
> version to the same catalog version because the catalog version is
> embedded in the tablespace directory name.

Well, it does work, but only because the regression tests don't keep a
tablespace around at the end.  Would pg_upgrade complain otherwise?

In response to

• Re: pg_upgrade automatic testing at 2011-09-01 22:55:19 from Bruce Momjian

Responses

• Re: pg_upgrade automatic testing at 2011-09-02 14:43:05 from Andrew Dunstan
• Re: pg_upgrade automatic testing at 2011-09-02 17:53:56 from Bruce Momjian

pgsql-hackers by date

Next:	From: Andrew Dunstan	Date: 2011-09-02 14:43:05
	Subject: Re: pg_upgrade automatic testing
Previous:	From: Kevin Grittner	Date: 2011-09-02 14:34:34
	Subject: Re: postgresql.conf archive_command example