Обсуждение: 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.

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