Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup andpg_receivewal --endpos - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup andpg_receivewal --endpos
Date
Msg-id eaf29163-200e-beff-10a2-c702fe0244e3@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup andpg_receivewal --endpos  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup andpg_receivewal --endpos
List pgsql-hackers
On 9/11/17 18:21, Michael Paquier wrote:
> On Tue, Sep 12, 2017 at 5:57 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> 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, perhaps by a function in TestLib, so it can be reused
>> in other tests.  (Even more robust would be to write out an actual Perl
>> file with configuration information somewhere, but maybe we don't need
>> to go there yet.)  Or maybe have the respective make variables exported
>> when make check is called (could be included in the prove_check
>> variable?).  Anyway, some more pondering could lead to a more general
>> solution.
> 
> There is always room for improvement,

I interpret that as that you are not working on that right now, so I've
closed this patch.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: [HACKERS] why not parallel seq scan for slow functions
Next
From: Tatsuro Yamada
Date:
Subject: Re: [HACKERS] CLUSTER command progress monitor