On Tue, Sep 12, 2017 at 9:19 PM, Peter Eisentraut
wrote:
> On 9/11/17 18:21, Michael Paquier wrote:
>> On Tue, Sep 12, 2017 at 5:57 AM, Peter Eisentraut
>> wrote:
>>> I think a more robust way would be to parse
>>> Makefile.global, perhaps by a function in TestLib, so it can be reused
>>> in othe
On 9/11/17 18:21, Michael Paquier wrote:
> On Tue, Sep 12, 2017 at 5:57 AM, Peter Eisentraut
> wrote:
>> I have committed this patch, after a perltidy run, but the way the libz
>> detection was implemented was a bit too hackish for me, so I have
>> omitted that for now.
>
> Thanks.
>
>> I think
On Tue, Sep 12, 2017 at 5:57 AM, Peter Eisentraut
wrote:
> I have committed this patch, after a perltidy run, but the way the libz
> detection was implemented was a bit too hackish for me, so I have
> omitted that for now.
Thanks.
> I think a more robust way would be to parse
> Makefile.global,
On 9/6/17 00:54, Michael Paquier wrote:
>> - 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.
>
> Let's address it now. This can be countered by querying pg_config()
> before running the com
On Tue, Sep 5, 2017 at 10:19 PM, Peter Eisentraut
wrote:
> On 6/9/17 02:08, Michael Paquier wrote:
>> 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 i
On 6/9/17 02:08, Michael Paquier wrote:
> On Wed, Jun 7, 2017 at 9:20 AM, Michael Paquier
> 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 --endpo
On Wed, Jun 7, 2017 at 9:20 AM, Michael Paquier
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
Hi all,
The coverage of pg_basebackup is reaching 50%, which is not bad:
https://coverage.postgresql.org/src/bin/pg_basebackup/index.html
In this set pg_receivewal.c is the bad student with less than 20%.
There are a couple of causes behind that, with no tests like:
- option interactions like --c
