|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Julien Rouhaud <rjuju123(at)gmail(dot)com>|
|Cc:||Andrew Dunstan <andrew(at)dunslane(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: SQL-standard function body|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> On Thu, Apr 08, 2021 at 02:58:02AM -0400, Tom Lane wrote:
>> No, because if that were the explanation then we'd be getting no
>> buildfarm coverage at all for for pg_stat_statements. Which aside
>> from being awful contradicts the results at coverage.postgresql.org.
> Is there any chance that coverage.postgresql.org isn't backed by the buildfarm
> client but a plain make check-world or something like that?
Hmm, I think you're right. Poking around in the log files from one
of my own buildfarm animals, there's no evidence that pg_stat_statements
is being tested at all. Needless to say, that's just horrid :-(
I see that contrib/test_decoding also sets NO_INSTALLCHECK = 1,
and the reason it gets tested is that the buildfarm script has
a special module for that. I guess we need to clone that module,
or maybe better, find a way to generalize it.
There are also some src/test/modules modules that set NO_INSTALLCHECK,
but apparently those do have coverage (modules-check is the step that
runs their SQL tests, and then the TAP tests if any get broken out
as separate buildfarm steps).
regards, tom lane
|Next Message||Simon Riggs||2021-04-08 16:29:25||Re: VACUUM (DISABLE_PAGE_SKIPPING on)|
|Previous Message||Alvaro Herrera||2021-04-08 16:19:16||Re: Autovacuum on partitioned table (autoanalyze)|