From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos |
Date: | 2017-09-05 13:19:55 |
Message-ID: | d687ec42-1da4-c6b9-61d7-ea5fd47e131a@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/9/17 02:08, Michael Paquier wrote:
> On Wed, Jun 7, 2017 at 9:20 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> While it is possible to tackle some of those issues independently,
>> like pg_basebackup stuff, it seems to me that it would be helpful to
>> make the tests more deterministic by having an --endpos option for
>> pg_receivewal, similarly to what exists already in pg_recvlogical.
>>
>> Thoughts?
>
> I have just played with that, and attached is a patch to implement the
> so-said option with a basic set of tests, increasing code coverage of
> pg_receivewal.c from 15% to 60%. I'll park that in the next CF of
> September.
Looks like a good idea. A couple of thoughts:
- I think the tests should be written in the style of
$node->command_fails instead of just command_fails. At least, that's
how it's done in the pg_basebackup tests.
- I think the tests will fail if libz support is not built. Again,
pg_basebackup doesn't have tests for that. So maybe omit that and
address it later.
- The variable exit_on_stop seems redundant with time_to_abort. They do
the same thing, so maybe your patch could reuse it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Vladimir Borodin | 2017-09-05 13:20:02 | Re: Proposal: pg_rewind to skip config files |
Previous Message | Tom Lane | 2017-09-05 13:18:53 | Re: pgbench tap tests & minor fixes. |