Re: pg_upgrade: Error out on too many command-line arguments

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade: Error out on too many command-line arguments
Date: 2019-08-30 14:55:05
Message-ID: alpine.DEB.2.21.1908301651290.28828@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>>> Is this issue *really* worth expending test cycles on forevermore?
>
>> With this argument consistently applied, postgres code coverage is
>> consistently weak, with 25% of the code never executed, and 15% of
>> functions never called. "psql" is abysmal, "libpq" is really weak.
>
> It's all a question of balance. If you go too far in the other
> direction, you end up with test suites that take an hour and a half
> to run so nobody ever runs them (case in point, mysql). I'm all for
> improving coverage in meaningful ways --- but cases like this seem
> unlikely to be worth ongoing expenditures of testing effort.

Sure.

I think there is room for several classes of tests, important ones always
run and others run say by the farm, and I thought that is what TAP tests
were for, given they are quite expensive anyway (eg most TAP test create
their own postgres instance).

So for me the suggestion was appropriate for a pgbench-specific TAP test.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2019-08-30 15:59:32 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Fabien COELHO 2019-08-30 14:50:21 Re: refactoring - share str2*int64 functions