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 20:11:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andrew Dunstan wrote:
> On 09/02/2011 01:55 PM, Bruce Momjian wrote:
> > 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 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, and it creates them with absolute path references
> >>>>> to  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.
> Why not use a prefix like 'd_' and 's_' so they can't be identical?

What would 'd' and 's' mean?  Destination and Source?  That doesn't help
us because a destination today might be a source tomorrow and we don't
rename these tablespace directory names.

  Bruce Momjian  <bruce(at)momjian(dot)us>

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

In response to

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2011-09-02 20:20:24
Subject: Re: postgresql.conf archive_command example
Previous:From: Kevin GrittnerDate: 2011-09-02 20:10:30
Subject: Re: postgresql.conf archive_command example

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