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

From Michael Paquier
Subject Re: Improving test coverage of extensions with pg_dump
Date
Msg-id CAB7nPqSEdYUvGZnnBwe0o7-QtfuN+2fWZ2GVqeM=mf2v99aHkg@mail.gmail.com
Whole thread Raw
In response to Re: Improving test coverage of extensions with pg_dump  (Andres Freund <andres@anarazel.de>)
Responses Re: Improving test coverage of extensions with pg_dump  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.
Regards,
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: pgsql: Improve logging of TAP tests.
Next
From: Steve Singer
Date:
Subject: Re: snapshot too old, configured by time