Hi,
On 2019-05-20 17:47:17 -0700, Andres Freund wrote:
> On 2019-05-20 20:19:20 -0400, Tom Lane wrote:
> > Andres Freund <andres@anarazel.de> writes:
> > > On 2019-05-20 14:09:40 -0400, Tom Lane wrote:
> > > 3) The fact that src/bin/pg_upgrade/Makefile invokes test.sh with
> > > MAKE=$(MAKE) triggers make, for reasons I do not yet understand, to
> > > *disable* output synchronization. Which annoys the heck out of me,
> > > because it makes parallel check output neigh unparsable.
> >
> > Probably the same thing as your 2)?
>
> It's not quite. I've not yet fully understood it yet. It's *not* tied to
> MAKEFLAGS. If I understand correctly, when make sees $(MAKE)/${MAKE} in
> a recipe, or the recipe starts with +, it assumes that the sub-command
> is *also* make. And the reason that output synchronization doesn't work
> is that make *intentionally* doesn't enable that for submakes - it only
> wants it for commands run by those submakes (otherwise it could not
> individually output individual targets processed in submakes).
>
> I think the right approach might be to just *never* invoke make inside
> test.sh:
> 1) We can fairly easily fix the make install to be unnecessary
> 2) I think the installcheck-parallel could be replaced by instead
> passing in the the necessary pg_regress command. That'd also have the
> benefit of not having another make invocation stat'ing a lot of files
> etc.
>
> I'll play with these.
1) was easy enough (posted at [1], and also attached here). I think 2)
is a bit harder, because according to src/bin/pg_upgrade/TESTING we
currently support invoking test.sh from commandline.
Therefore I think we ought to just work around that make heuristic, by
referring to $(MAKE) via an indirection. Like in the attached. After
that I don't get any interspersed output anymore if I run with -Otarget.
Greetings,
Andres Freund
[1] https://postgr.es/m/20190521191918.z7kwnrlj45mk2k67%40alap3.anarazel.de