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