Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test - Mailing list pgsql-hackers
From | Michael Paquier |
---|---|
Subject | Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test |
Date | |
Msg-id | CAB7nPqQEjkv1gQUoCLR+GrNS6AmVjks9UsD+SQJFPGRTFkKQSQ@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Responses |
Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test
|
List | pgsql-hackers |
On Wed, Sep 6, 2017 at 10:05 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > Please send a rebased patch. > > I propose splitting the single Perl script into three separate test > files: one for basic command-line option handling and so on (I would > like to expand that later), one for the main upgrade test, and one for > the funny database names tests. That makes sense. There will be additional overhead with the creation of an extra server though. > In the testing file, you removed the paragraph that explains how to do > cross-version upgrade testing. It's unfortunate that we would lose that > functionality. What can we do about that? Right, simply removing support for something which has been here for a long time is no fun. I think that we should add in PostgresNode objects a new bindir variable which will be used to define path to binaries. Any new node created needs to go through init() or init_from_backup(), so a node created with init() would set this bindir to what pg_config in PATH reports, or to the value defined by the caller if it is defined (let's use an option for %params). A node created from init_from_backup() inherits the path of its root node. This requires a bit of refactoring first. This could help also for cross version tests out of the code core. In the existing scripts, there are the following variables: - oldsrc, old version's source tree - oldbindir, old version's installed bin dir - bindir, this version's installed bin dir. - libdir, this version's installed lib dir bindir and libdir are pointing to the currently installed version in the tree, so we could do without it, no? oldbindir and oldsrc need to be kept around to enforce the position of binaries for the old version, as well as a proper shape of the original dump being compared (+ drop of the past functions). Then, for the pg_upgrade tests, let's check for ENV{oldbindir} and enforce the bindir value of the PostgresNode to-be-upgraded. And also for ENV{oldsrc}, first check if it is defined, and then do the existing psql/dump changes. So one, in order to run cross-version checks, would just need to rely on the fact that the version where installcheck runs is the new version. Does that sound acceptable? Looking at 5bab198, those don't run that often, but I definitely agree that breaking something for no apparent reason is not cool either ;p > We also need to have a plan for handling the build farm. Maybe keep the > vcregress.pl upgradecheck target as a thin wrapper for the time being? Or we could make upgradecheck a noop, then remove it once all the MSVC animals have upgraded to a newer version of the buildfarm client which does not use upgradecheck anymore (I am fine to send a patch or a pull request to Andrew for that). -- Michael
pgsql-hackers by date: