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

Fabien COELHO <coelho@cri.ensmp.fr>

From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, Michael Paquier <michael@paquier.xyz>, Julien Rouhaud <rjuju123@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-08-30T14:55:05Z
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.



Commits

  1. Error out on too many command-line arguments