Re: pgsql: Address portability issues in bfe16d1a5 test output. - Mailing list pgsql-committers

From Andres Freund
Subject Re: pgsql: Address portability issues in bfe16d1a5 test output.
Date
Msg-id 20160913013537.ln2sv3r5qfmp7w7u@alap3.anarazel.de
Whole thread Raw
In response to Re: pgsql: Address portability issues in bfe16d1a5 test output.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Address portability issues in bfe16d1a5 test output.  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Address portability issues in bfe16d1a5 test output.
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Address portability issues in bfe16d1a5 test output.