On Wed, Sep 16, 2015 at 3:42 PM, Andres Freund <andres@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 <andres@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