Re: submake-errcodes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Devrim Gündüz <devrim(at)gunduz(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: submake-errcodes
Date: 2018-04-10 19:04:22
Message-ID: 24426.1523387062@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Hm ... you're cd'ing into src/pl/plpython and issuing "make all"?
> That works for me.
> ... or, wait ... with -j it doesn't. That's strange, will look.

So after a bit of digging, it seems that the locution

all: submake-generated-headers

doesn't result in ensuring that submake-generated-headers is complete
before we go to build the other targets required by "all"; it only
says that submake-generated-headers must be complete before we execute
the (empty) list of commands attached to the "all" target.

I'd tested high-j runs pretty carefully at top level, but it turns
out that that works because in both the toplevel GNUmakefile and
src/Makefile, all the interesting work happens in recursive sub-makes,
and we force the ordering of those properly with the dependencies on
the recursive make rules:

$(1)-$(2)-recurse: $(if $(filter all install, $(3)), submake-generated-headers) $(if $(filter check, $(3)), temp-install)
$$(MAKE) -C $(2) $(3)

If you go to, eg, src/pl/plpython and issue "make -j", there's nothing
to prevent the builds of object files from happening before the header
build finishes. There *was* something there before:

$(OBJS): | submake-generated-headers

but I took it out thinking it was no longer needed.

The short-term solution seems to be to put that back, but that's sort
of annoying because it means this isn't a bulletproof solution. It
will only work for builds started in one of the directories that we
take the trouble to put this defense into, and I can't see doing that
everywhere. Still, such things didn't work reliably before either
except in these few directories, so maybe it won't matter.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-04-10 19:17:49 Re: Reopen logfile on SIGHUP
Previous Message Joshua D. Drake 2018-04-10 18:58:37 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS