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

Re: pg_upgrade automatic testing

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade automatic testing
Date: 2011-09-02 20:00:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

On 09/02/2011 03:04 PM, Tom Lane wrote:
> Bruce Momjian<bruce(at)momjian(dot)us>  writes:
>> Andrew Dunstan wrote:
>>> 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.
> IMO there's next to no value in testing that scenario anyway, since
> nobody would ever use it in the field.  What *would* be of value is
> testing upgrades from previous release versions.  Probably that will
> take some work in the buildfarm infrastructure as well as figuring out a
> non-problematic test case to use, but that's the direction we need to
> head in.

I'm working on this right now.

Basically the idea is to stash away build and data dirs (after we've run 
regression, PL and contrib testing) for stable branches (via a command 
line option) and then test upgrading them. A trial run on the first part 
is currently running. Once I have that sorted out I'll work on the 
testing bit ;-)



In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-09-02 20:04:48
Subject: Re: PATCH: regular logging of checkpoint progress
Previous:From: Tomas VondraDate: 2011-09-02 19:52:37
Subject: Re: PATCH: regular logging of checkpoint progress

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