On 2013-12-10 19:55:12 -0500, Tom Lane wrote:
I was surprised to see that my back-patches of the recent SubLink
unpleasantness were failing on many of the buildfarm members, but
only in the 9.1 and 9.0 branches. The difficulty appears to be
that the EXPLAIN output for the new test query
Tom Lane t...@sss.pgh.pa.us wrote:
I haven't touched matview.sql here; that seems like a distinct issue.
I'll fix that.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Kevin Grittner kgri...@ymail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I haven't touched matview.sql here; that seems like a distinct
issue.
I'll fix that.
Done.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-10 19:55:12 -0500, Tom Lane wrote:
We need a more consistent strategy for this :-(
Agreed, although I have no clue how it should look like. As a further
datapoint I'll add that installcheck already regularly fails in HEAD if
you have a
On 2013-12-11 10:07:19 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-10 19:55:12 -0500, Tom Lane wrote:
We need a more consistent strategy for this :-(
Agreed, although I have no clue how it should look like. As a further
datapoint I'll add that
Kevin Grittner kgri...@ymail.com writes:
Kevin Grittner kgri...@ymail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I haven't touched matview.sql here; that seems like a distinct issue.
I'll fix that.
Done.
Thanks.
regards, tom lane
--
Sent via pgsql-hackers
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-11 10:07:19 -0500, Tom Lane wrote:
Do you remember offhand where the failures are?
No, but they are easy enough to reproduce. Out of 10 runs, I've attached
the one with the most failures and checked that it seems to contain all
the
On Tue, Dec 10, 2013 at 7:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This doesn't make me happy. Aside from the sheer waste of cycles
involved in re-analyzing the entire regression database, this
test runs in parallel with half a dozen others, and it could cause
plan instability in those. Of
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 10, 2013 at 7:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Anyway, bottom line is that I think we need to institute, and
back-patch, some consistent scheme for when to analyze the standard
tables during the regression tests, so that we don't
