From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jack Kelly <jack@jackkelly.name>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #15525: Build failures when compiling Postgres with Make parallelization
Date: Thu, 29 Nov 2018 11:03:05 -0500
Message-ID: <28445.1543507385@sss.pgh.pa.us> (raw)
In-Reply-To: <87r2f4jfu0.fsf@jackkelly.name>
References: <15525-a30da084f17a1faa@postgresql.org>
<31602.1543363896@sss.pgh.pa.us>
<87k1kwlvad.fsf@jackkelly.name>
<28417.1543458718@sss.pgh.pa.us>
<CAEepm=3wHjf9ZfekMq5x0qs_r1XBd0YXTrhoZMbmDx-xE8NXwA@mail.gmail.com>
<31059.1543461919@sss.pgh.pa.us>
<CAEepm=3WXu0Ke8AB3i9Z8EdKZ_RajcKrkwj1GTkgcdqdaafjqw@mail.gmail.com>
<87r2f4jfu0.fsf@jackkelly.name>
Jack Kelly <jack@jackkelly.name> writes:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>> As for what could be done about it, it seems like we (or the Nix
>> project, in a local patch) could declare individual targets to have
>> .LOW_RESOLUTION_TIME:
>> https://www.gnu.org/software/make/manual/html_node/Special-Targets.html
>> That doesn't seem any better than using "touch" to make a better mtime
>> though.
In fact it's worse, because it opens you up to the same problems that
sub-second timestamps were meant to fix.
After sleeping on this, I'm liking the idea of adding "touch" to our
rule better. We shouldn't imagine that this problem exists in a vacuum:
Apple got that ranlib code from some BSD or other, so it probably
exists in similar form elsewhere. And filesystems with sub-second
timestamps are getting more common. So it seems likely that this issue
could manifest on other combinations than the one we see here.
> IMHO, The Nth-degree "correct" thing for the postgresql build system
> would be check if the most recent versions are vulnerable, and if so
> update the configure script to detect a high-resolution filesystem and a
> truncating ranlib, and if that is true for that build, then set a
> variable so the Makefiles can conditionally add static libraries to
> `.LOW_RESOLUTION_TIME` targets. This seems like a lot of work for
> marginal payoff, particularly if releases newer than 9.x are not brittle
> in this way.
The issue is still there in the same form. I agree that this sketch
of the "correct" thing is not going to happen, though. The "touch"
fix seems like a far more appropriate level of effort, plus it actually
fixes the problem rather than applying a band-aid. (I have checked
that "touch" applies a sub-second timestamp on APFS, btw.)
> 3. This bug seems to be tickled because two different Makefiles use
> attempt to build the same target at the same time, using a tool
> (macOS libtool/ranlib, albeit through a recursive $(MAKE) invocation)
> that doesn't support subsecond timestamps, on a filesystem that does
> (APFS). That's a bit of a corner case.
Yeah, this. Under typical circumstances, the worst that would happen
is an extra rebuild of the .a file. We're unlucky because two such
rebuilds could get launched in parallel, something that I bet is not
that common.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, jack@jackkelly.name, thomas.munro@enterprisedb.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15525: Build failures when compiling Postgres with Make parallelization
In-Reply-To: <28445.1543507385@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox