postgresql: backport parallel-make on macOS?

[endgame]

Issue description

Continues #51093. Parallel builds of postgresql have been disabled on darwin as a blunt fix. A patch was recently posted to the pgsql-bugs mailing list to fix this: https://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=826eff57c4c23f77314ba7151d3dc506ce0fa24c

We may want to integrate this patch into nixpkgs, as the next upstream release is scheduled for February. I won't have time to do this, I'm afraid.

Ping @delroth , who can decide whether this is a worthwhile thing to backport, and close if not.

[delroth]

I think I'd rather see ranlib fixed as we talked about in #51221, if we can make it work.

[endgame]

Cool. I'll leave this for you to close, then, once you decide whether the ranlib patches are going to work?

[thoughtpolice]

Yes, this should be done in ranlib if possible and it can be fixed for all our Darwin builds. It seems like Postgres might not be the first or last to suffer from this.

[matthewbauer]

I would not count on the fix being backported to 18.09. It depends on what we end up agreeing on. We may have to expose utimensat which is only available on macOS 10.13, breaking support for previous versions. That should probably just go to unstable. Just disabling parallel building in the latest release sounds like the safest idea to me.

[endgame]

@matthewbauer This bug isn't about backporting the ranlib fix to 18.09, but about backporting a build-system fix the postgres devs have proposed (the target for the .a file that the build races over gets an extra touch $@, which supports subsecond timestamps).

[endgame]

The answer the question asked by this issue is "no", as that the patch to turn off subsecond timestamps on Darwin builds of gnumake just landed (#51408).