Re: SQL-standard function body - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQL-standard function body
Date
Msg-id 1884374.1617898865@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL-standard function body  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: SQL-standard function body  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Julien Rouhaud <rjuju123@gmail.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Autovacuum on partitioned table (autoanalyze)
Next
From: Simon Riggs
Date:
Subject: Re: VACUUM (DISABLE_PAGE_SKIPPING on)