On Tue, Oct 13, 2015 at 3:47 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Aug 18, 2015 at 12:08 PM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: >> Robert Haas wrote: >>> On Sat, Aug 15, 2015 at 6:45 PM, Mark Johnston <ma...@freebsd.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.1444928...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers