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

From Michael Paquier
Subject Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.
Date
Msg-id CAB7nPqSkYPKqHEnFhuf0+dxO2m+MxAThitax9doxXRat8iL0vg@mail.gmail.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Oct 13, 2016 at 8:38 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-10-12 11:18:57 -0400, Peter Eisentraut wrote:
>> On 10/4/16 11:29 AM, Tom Lane wrote:
>> > Robert Haas <robertmhaas@gmail.com> writes:
>> >> Apparently, 'make world' does not build worker_spi.  I thought 'make
>> >> world' was supposed to build everything?
>> >
>> > You'd have thunk, yeah.  It looks like the issue is that src/Makefile
>> > is selective about recursing into certain subdirectories of test/,
>> > but mostly not test/ itself.  src/test/Makefile naively believes it's
>> > in charge, though.  Probably that logic ought to get shoved down one
>> > level, and then adjusted so that src/test/modules gets built by "all".
>> > Or else teach top-level "make world" to do "make all" in src/test/,
>> > but that seems like it's just doubling down on confusing interconnections.
>>
>> We generally don't build test code during make world.
>
> FWIW, I find that quite annoying. I want to run make world with parallelism so
> I can run make world afterwards with as little unnecessary
> unparallelized work. And since the latter takes just about forever, any
> errors visible earlier are good.
>
> What are we gaining by this behaviour?

Personally, I have been trapped by the fact that worker_spi does not
get built when doing a simple check-world recently... So +1 for just
building it when running check-world. We gain nothing with the current
behavior except alarms on the buildfarm.
-- 
Michael



pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: macaddr 64 bit (EUI-64) datatype support
Next
From: Tom Lane
Date:
Subject: Re: Change of extension name to new name