On Wed, Sep 16, 2015 at 3:42 PM, Andres Freund <and...@anarazel.de> wrote: > On 2015-09-09 10:48:24 +0900, Michael Paquier wrote: >> On Wed, Sep 9, 2015 at 3:33 AM, Andres Freund <and...@anarazel.de> wrote: >> > On 2015-09-07 22:55:50 +0900, Michael Paquier wrote: >> >> So, to summarize the state of this patch whose status is now "Waiting >> >> on Author", we have the following possibilities: >> >> 1) Keep the test as-is, as an independent test of src/test/modules. >> > >> > I find that a bad option. A test that takes this long and has that much >> > setup for such a marginal amount of coverage just doesn't seem worth it. >> > >> >> 2) Integrate it in the test suite of src/test/regress and let >> >> pg_upgrade make the work with dump/restore. >> > >> > 2b) ... and create a single src/test/modules/pg_dumprestore test that >> > initdbs, runs installcheck, dumps, loads and compares a repated dump. >> > >> > I think 2b) is by far the best choice. >> >> And I guess that the extensions tested should be located directly in >> this path, or we would need again to tweak the MSVC scripts... >> Attached is an attempt to solve things by converting the previous >> patch as proposed by Andres. A source and a target databases are used >> on a cluster, and their respective dumps are compared with >> File::Compare (available down to perl 5.8.8) at the end. > > Unless I miss something this isn't 2b) as it does *not* actually run > the actual installcheck. Therefore the actual pg_dump/restore coverage > is neglegible.
Hm. OK. I didn't get your message correctly, sorry for that. Would you be fine then to have a pg_regress command using parallel_schedule + an extra schedule launching tests related to the extensions in src/test/modules/pg_dumprestore then? The choice of parallel_schedule is based on what Windows does, aka this schedule is used in the equivalent of make check in vcregress.pl. The TAP script then simply initializes the cluster, runs pg_regress, and does the dump/restore job. There is no real need to worry about setval as dump is not taken from a standby.. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
