Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regressiontests and code coverage - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regressiontests and code coverage
Date
Msg-id 20170320150609.GP9812@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> New tests are not zero-cost; they create a distributed burden on the
> buildfarm and, by increasing the buildfarm cycle time, slow down feedback
> to authors of subsequent patches.  So I'm very much not on board with
> any argument that "more tests are always better and don't even require
> discussion".

I agree with that and certainly considered it while working on these
added tests.

> I'd have liked to see this patch posted with some commentary along the
> lines of "this improves LOC coverage in pg_dump by X%, and for me it
> increases the time taken for 'make installcheck' in bin/pg_dump by Y%".
> Assuming Y isn't totally out of line with X, I doubt anyone would have
> objected or even bothered to review the patch in detail ... but it would
> have been polite to proceed that way.

About 8% increased LOC coverage for pg_dump.c (which isn't small when
you consider how large that file is).  The additional time seemed to be
on the 5-6s range, moving the test from 35s to 40s or so.

> In short, I agree with Stephen's position that test additions can get
> away with less review than other sorts of changes, but I also agree with
> Robert's position that that doesn't mean there's no process to follow
> at all.

Fair enough.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Ronan Dunklau
Date:
Subject: Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering
Next
From: Teodor Sigaev
Date:
Subject: Re: [HACKERS] PinBuffer() no longer makes use of strategy