Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.
Date
Msg-id CA+TgmoYNwrqhYnApx4FACW0eZ1n7qWEmxvG=w91A_WJT7NLWag@mail.gmail.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Oct 14, 2016 at 11:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Oct 14, 2016 at 9:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> TBH, I can't muster much sympathy for that position.  Make a test case
>>> for it, and the problem goes away, not to mention that confidence in
>>> whether it actually works (not just compiles) goes up a lot.
>
>> I'm not sure there's an easy way to test it via pg_regress, but if
>> somebody can come up with something, sure.  But why stick to a rule
>> that is inconvenient for no real benefit?  Compiling everything in
>> src/test/modules when someone runs 'make check-world' would take a
>> handful of seconds and prevent developer errors like the one that
>> started this thread.  That seems like a slam-dunk from here,
>> regardless of anything else.
>
> I guess what I'm having a problem with is something that lives under
> src/test/ and is not in fact intended as a test.  If you're not interested
> in making it into a live test, it's in the wrong place.  You might as
> well complain that you put C code under doc/src/sgml/ and it didn't get
> compiled.

Well, we could move worker_spi back to contrib.

> One idea is to put "check: all" into its makefile, if there's no prospect
> of check doing something more than that.

That'd certainly be better than doing nothing.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: tablesample test failure with small TOAST_TUPLE_THRESHOLD
Next
From: Tom Lane
Date:
Subject: Re: signal handling in plpython