public inbox for [email protected]  

help / color / mirror / Atom feed

From: Stephen Frost <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: PostgreSQL mailing lists <[email protected]>
Cc: Noah Misch <[email protected]>
Subject: Re: Rewriting the test of pg_upgrade as a TAP test
Date: Mon, 3 Apr 2017 11:34:52 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAB7nPqRdaN1A1YNjxNL9T1jUEWct8ttqq29dNv8W_o37+e8wfA@mail.gmail.com>
	<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>

Peter,

* Peter Eisentraut ([email protected]) wrote:
> On 4/3/17 09:07, Michael Paquier wrote:
> > I had for some time a WIP patch on which dust has accumulated, so
> > attached is a more polished version. In more details, here is what
> > happens:
> > - test.sh is removed.
> > - vcregress.pl loses upgradecheck.
> > - The new test is added. In the case of MSVC this is now part of bincheck.
> > Patch has been tested on macos and Windows.
> 
> This is a useful start.  What I'd really like to see is that instead of
> running the full serial tests to populate the pre-upgrade database, we
> determine a useful subset of what that ends up generating and just
> populate with that.

In the past, we've had the notion that the regression tests are intended
to also cover pg_upgrade/pg_dump by "leaving things around".  What I
found in my efforts to provide better coverage in pg_dump is that there
was quite a bit of coverage missing using that approach.

Perhaps that could be fixed, but I tend to think it's a better approach
to have a complete set of pg_upgrade/pg_dump tests in one place that
doesn't also have a bunch of other tests mixed in (and would also mean
that the regular regression tests could be 'clean').

I could also see us defining one set of commands to run which create
every type of object in the system that pg_dump understands and then
using that to perform the pg_dump and pg_upgrade tests.  Those commands
would have to be annotated with minimum major version and maximum major
version, assuming we're going to use them cross-version, but that should
be reasonably straight-forward to do.

Another question is how much sense it makes to test this logic,
essentially, twice.  The testing of pg_dump covers the pg_dump code,
which is what pg_upgrade uses anyway.  The pg_upgrade tests really need
to cover the non-pg_dump-related parts, assuming we have appropriate
coverage in the pg_dump tests for the --binary-upgrade mode.  Of course,
if we don't, then we should go about fixing that.  There are certainly
some tests now but perhaps we need more or need to have improvmenets
made there.

Thanks!

Stephen


Attachments:

  [application/pgp-signature] signature.asc (819B, ../[email protected]/2-signature.asc)
  download

view thread (113+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Rewriting the test of pg_upgrade as a TAP test
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox