Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade automatic testing

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade automatic testing
Date: 2011-09-02 17:55:12
Message-ID: 201109021755.p82HtCb26216@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andrew Dunstan wrote:
> 
> 
> On 09/02/2011 10:36 AM, Peter Eisentraut wrote:
> > 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 any case, it would be good to get rid of the limitation if possible. 
> Then we could look at creating an automated test that we could use in 
> the buildfarm.

Well, the idea of using the catalog version was that it is something we
expect would change during any change in the system catalogs or internal
data format that would require the use of pg_upgrade.  I am unclear what
other fixed value we could use for this.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

Responses

pgsql-hackers by date

Next:From: Jaime CasanovaDate: 2011-09-02 18:12:40
Subject: Re: WAL "low watermark" during base backup
Previous:From: Bruce MomjianDate: 2011-09-02 17:53:56
Subject: Re: pg_upgrade automatic testing

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group