Does parallel make require guards against duplicate actions?
The old Gen_fmgrtab.sh script used temporary file names that included
its process PID. It had this comment about that:
# We use the temporary files to avoid problems with concurrent runs
# (which can happen during parallel make).
The new implementation uses temp files that just have ".tmp" appended to
the target file name. If there is a risk that "make -j" will run the
same action twice in parallel, this isn't good enough. While it
wouldn't be too tough to add the PID to the scripts, I wonder whether
this comment is about a real problem or just a flight of fancy. It
doesn't seem to me that parallel make ought to be stupid enough to
do the same action twice. Anybody know?
regards, tom lane
FWIW, the old make rule was
fmgroids.h fmgrtab.c: (deps)
which is now
fmgroids.h: fmgrtab.c ;
fmgrtab.c: (deps)
I was going by this comment in parser/Makefile:
# There is no correct way to write a rule that generates two files.
# Rules with two targets don't have that meaning, they are merely
# shorthand for two otherwise separate rules. To be safe for parallel
# make, we must chain the dependencies like this.
Show quoted text
On Mon, Jan 4, 2010 at 6:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
The old Gen_fmgrtab.sh script used temporary file names that included
its process PID. It had this comment about that:# We use the temporary files to avoid problems with concurrent runs
# (which can happen during parallel make).The new implementation uses temp files that just have ".tmp" appended to
the target file name. If there is a risk that "make -j" will run the
same action twice in parallel, this isn't good enough. While it
wouldn't be too tough to add the PID to the scripts, I wonder whether
this comment is about a real problem or just a flight of fancy. It
doesn't seem to me that parallel make ought to be stupid enough to
do the same action twice. Anybody know?regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On mån, 2010-01-04 at 21:58 -0500, Tom Lane wrote:
The old Gen_fmgrtab.sh script used temporary file names that included
its process PID. It had this comment about that:# We use the temporary files to avoid problems with concurrent runs
# (which can happen during parallel make).The new implementation uses temp files that just have ".tmp" appended to
the target file name. If there is a risk that "make -j" will run the
same action twice in parallel, this isn't good enough. While it
wouldn't be too tough to add the PID to the scripts, I wonder whether
this comment is about a real problem or just a flight of fancy. It
doesn't seem to me that parallel make ought to be stupid enough to
do the same action twice. Anybody know?
When you have only one makefile, this shouldn't happen if the rules are
written correctly. But when the parallel make is initiated from the
top, plus a decade-old buggy gmake, anything can happen. :-/ It's
probably worth the small extra effort to be robust against this when the
alternative is possible slightly butchered catalog files.
Peter Eisentraut <peter_e@gmx.net> writes:
On mån, 2010-01-04 at 21:58 -0500, Tom Lane wrote:
The new implementation uses temp files that just have ".tmp" appended to
the target file name. If there is a risk that "make -j" will run the
same action twice in parallel, this isn't good enough. While it
wouldn't be too tough to add the PID to the scripts, I wonder whether
this comment is about a real problem or just a flight of fancy. It
doesn't seem to me that parallel make ought to be stupid enough to
do the same action twice. Anybody know?
When you have only one makefile, this shouldn't happen if the rules are
written correctly. But when the parallel make is initiated from the
top, plus a decade-old buggy gmake, anything can happen. :-/ It's
probably worth the small extra effort to be robust against this when the
alternative is possible slightly butchered catalog files.
OK, I'll go fix that.
regards, tom lane