Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

2017-09-12 Thread Michael Paquier
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 >>>

Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

2017-09-12 Thread Peter Eisentraut
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

Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

2017-09-11 Thread Michael Paquier
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

Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

2017-09-11 Thread Peter Eisentraut
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

Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

2017-09-05 Thread Michael Paquier
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 >>

Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

2017-09-05 Thread Peter Eisentraut
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

Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

2017-06-09 Thread Michael Paquier
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 >

[HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

2017-06-06 Thread Michael Paquier
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