| From: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> | 
| Cc: | Mark Johnston <markj(at)freebsd(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: DTrace build dependency rules | 
| Date: | 2015-10-15 17:18:35 | 
| Message-ID: | CA+TgmoZGscqVrUYixBB8DhZSEYar=RjaSdcuuFxgidMjDd6Y6g@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Tue, Oct 13, 2015 at 3:47 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Aug 18, 2015 at 12:08 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>> Robert Haas wrote:
>>> On Sat, Aug 15, 2015 at 6:45 PM, Mark Johnston <markj(at)freebsd(dot)org> wrote:
>>
>>> > The bug is in src/backend/Makefile. probes.o, the dtrace(1)-generated
>>> > object file, depends on the objfiles.txt for each of the backend
>>> > subdirs. These files depend in turn on the object files themselves; if
>>> > objfiles.txt is out of date with respect to one of its object files, the
>>> > mtime of objfiles.txt is updated with "touch" (see backend/common.mk).
>>> > The problem is that dtrace -G, which runs at the end of the build,
>>> > modifies a number of object files (it overwrites their probe sites with
>>> > NOPs), thus making their corresponding objfiles.txt out of date. Then,
>>> > when "make install" traverses the backend subdirs, it updates
>>> > objfiles.txt, which causes probes.o to be rebuilt, resulting in an error
>>> > from dtrace(1).
>>>
>>> Gosh, that's pretty ugly.  I would have thought it would be a real
>>> no-no to update the .o file once it got generated.  If nothing else, a
>>> modification to the .c file concurrent with a make invocation might
>>> lead to the .o not getting rebuilt the next time make is run.
>>
>> I had the same thought, and wondered for a bit whether we should instead
>> have the compilation rules produce some intermediate file (prior to
>> dtrace fumbling), then emit the .o from dtrace -G.  OTOH this might be
>> more trouble than is worth for a feature that doesn't see a lot of use.
>
> Given the lack of further interest from the PostgreSQL community,
> that's my guess.  I've pushed this patch to master; let's see if we
> get any complaints.  If it makes life better for FreeBSD without
> making life worse for anyone else, I suppose we might as well do it
> until something better comes along.
Per http://www.postgresql.org/message-id/24541.1444928519@sss.pgh.pa.us
I have had to revert this patch, because it's breaking parallel builds
even for non-dtrace users.
Sorry for the inconvenience.
-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-10-15 17:23:23 | Re: [COMMITTERS] pgsql: Have dtrace depend on object files directly, not objfiles.txt | 
| Previous Message | Robert Haas | 2015-10-15 17:16:47 | Re: [COMMITTERS] pgsql: Have dtrace depend on object files directly, not objfiles.txt |