Re: coverage.postgresql.org not being refreshed

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: coverage.postgresql.org not being refreshed
Дата
Msg-id
1512519.1611453682@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
coverage.postgresql.org not being refreshed Peter Geoghegan <pg@bowt.ie>
Re: coverage.postgresql.org not being refreshed Magnus Hagander <magnus@hagander.net>
Re: coverage.postgresql.org not being refreshed Tom Lane <tgl@sss.pgh.pa.us>
Re: coverage.postgresql.org not being refreshed Magnus Hagander <magnus@hagander.net>
Re: coverage.postgresql.org not being refreshed Tom Lane <tgl@sss.pgh.pa.us>
Re: coverage.postgresql.org not being refreshed Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: coverage.postgresql.org not being refreshed Tom Lane <tgl@sss.pgh.pa.us>
Re: coverage.postgresql.org not being refreshed Tom Lane <tgl@sss.pgh.pa.us>
Re: coverage.postgresql.org not being refreshed Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: coverage.postgresql.org not being refreshed Tom Lane <tgl@sss.pgh.pa.us>
Re: coverage.postgresql.org not being refreshed Peter Geoghegan <pg@bowt.ie>
I wrote:
> Alvaro Herrera  writes:
>> Is there a convenient way to compare two coverage runs?

> Hmm ... diff'ing the html output is really painful, but it
> looks like using checktcp instead of check causes 48 lines
> in ecpg to change from not-covered to covered.

Enlarging on that a little: the coverage in src/interfaces/ecpg
changes from
	11860/(11860+12555.) = 0.48577
to
	11908/(11908+12507.) = 0.48773

Meanwhile, the coverage in src/interfaces/libpq changes from
	2421/(2421+4488.) = 0.35041
to
	2481/(2481+4428.) = 0.35910

and the whole-system coverage from
	256632/(256632+163564.) = 0.61074
to
	256839/(256839+163357.) = 0.61124

This is comparing coverage reports for the core regression tests
plus ecpg "make check" versus core plus ecpg "make checktcp".

The increase in coverage outside ecpg is presumably because
we otherwise aren't hitting TCP-socket code paths at all,
while Unix-socket code is covered in both cases.  So it's only
fair to include the non-ecpg coverage increase as a benefit
if you suppose that no other tests will hit the TCP code paths.
That might well have been true awhile ago, but I think that the
SSL and Kerberos tests are now covering much of that territory
(if coverage.postgresql.org is running those?)

			regards, tom lane


В списке pgsql-www по дате отправления
От: Tom Lane
Дата:
От: Magnus Hagander
Дата:
Сообщение: Re: missing ML messages
FAQ