Re: pgsql: Make VACUUM accept 1 and 0 as a boolean value.
От | Andres Freund |
---|---|
Тема | Re: pgsql: Make VACUUM accept 1 and 0 as a boolean value. |
Дата | |
Msg-id | 20190520203505.zoeitjlehqypgx26@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pgsql: Make VACUUM accept 1 and 0 as a boolean value. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Make VACUUM accept 1 and 0 as a boolean value.
|
Список | pgsql-committers |
Hi, On 2019-05-20 14:09:40 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2019-05-20 13:46:55 -0400, Tom Lane wrote: > >> If there were a way to get prove to be absolutely quiet (its --quiet is > >> a joke unfortunately), I'd lobby for a switch to make pg_regress quiet > >> too. The amount of useless noise this recipe generates is annoying, > >> and tends to make it hard to find where the actual error is when > >> there is one. > > > Indeed. Couldn't we just invent that on our end? I.e. in our prove > > invocation, just redirect the output? > > What I'd like, for both prove and pg_regress, is to print something > about failing tests and otherwise be quiet. Simple redirection won't > do that. Plus it'd be hard to fit that in with the case where you > don't want it to be quiet. Ah, I thought of just doing something roughly (in real syntax etc) like if QUIET_TEST: $(PROVE) $(PROVE_FLAGS) ... > $(CURDIR)/prove.log 2>&1 && echo prove in $CURDIR succeeded || echo prove in $CURDIR failed else $(PROVE) $(PROVE_FLAGS) ... maybe additionally outputting the path to the logfile in the failure case. While far from being as good as what you're desiring, it still seems like it could be a huge improvement over the status quo nevertheless? > > The most annoying noise imo is the pg_upgrade test. The set -x and the > > fact that it resets MAKEFLAGS makes that pretty annoying. > > Agreed, that could be improved independently of other things. Hm, there's a lot of oddities around the pg_upgrade test: 1) we still do an "open coded" install, regardless of dcae5faccab64 And that's *in addition* to to the install from dcae5faccab64. That seems pretty unnecessary. 2) We overwrite MAKELEVEL, MAKEFLAGS, breaking jobserver etc - that shouldn't be required anymore if test.sh were to be changed to behave like dcae5faccab64 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. 4) set -x spews a lot of things Greetings, Andres Freund
В списке pgsql-committers по дате отправления: