Re: pgsql: Address portability issues in bfe16d1a5 test output.
От | Andres Freund |
---|---|
Тема | Re: pgsql: Address portability issues in bfe16d1a5 test output. |
Дата | |
Msg-id | 20160913013537.ln2sv3r5qfmp7w7u@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pgsql: Address portability issues in bfe16d1a5 test output. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Address portability issues in bfe16d1a5 test output.
|
Список | pgsql-committers |
On 2016-09-12 21:33:03 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2016-09-12 21:25:05 -0400, Tom Lane wrote: > >> Hm, lapwing says this can't run in parallel with "misc" either :-( > > > Gah. That's probably why I had originally had it running in the rules > > group. But isn't that user_relns() test just a bad idea independent of > > this failure? I mean what's the benefit of returning all relations > > there, besides causing regression test churn? > > It looks like making your tables temp would work around it ... Right. But the more general question about the value of that test remain. Not that the tables in this test matter given how simple they are, but in general it doesn't hurt to have objects survive the regression tests, to increase dump coverage. Shouldn't we just drop that test? Andres
В списке pgsql-committers по дате отправления: