Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regressiontests and code coverage

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regressiontests and code coverage
Дата
Msg-id 20170320150609.GP9812@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Ronan Dunklau
Дата:
Сообщение: Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: [HACKERS] PinBuffer() no longer makes use of strategy