Re: Improving test coverage of extensions with pg_dump - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Improving test coverage of extensions with pg_dump
Date
Msg-id 20150909002127.GB3906@momjian.us
Whole thread Raw
In response to Re: Improving test coverage of extensions with pg_dump  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Wed, Sep  2, 2015 at 02:30:33PM -0300, Alvaro Herrera wrote:
> > I think we should rather add *one* test that does dump/restore over the
> > normal regression test database. Something similar to the pg_upgrade
> > tests. And then work at adding more content to the regression test
> > database - potentially sourcing from src/test/modules.
> 
> That's another option, but we've had this idea for many years now and it
> hasn't materialized.  As I recall, Andrew Dunstan has a module that
> tests cross-version pg_upgrade and one thing he does is dump both and
> compare; the problem is that there are differences, so he keeps a count
> of how many lines he expect to differ between any two releases.  Or
> something like that.  While it's a good enough start, I don't think it's
> robust enough to be in core.  How would we do it?

I have shell scripts that test pg_dump restore/upgrade of every
supported PG version.  I also have expected pg_dump output files for
every major version.  This is explained in src/bin/pg_upgrade/TESTING.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Counting lines correctly in psql help displays
Next
From: Noah Misch
Date:
Subject: Re: pgsql: Improve logging of TAP tests.