Re: Why the buildfarm is all pink - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Why the buildfarm is all pink
Date
Msg-id 20131211111206.GB1721@awork2.anarazel.de
Whole thread Raw
In response to Why the buildfarm is all pink  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why the buildfarm is all pink
List pgsql-hackers
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 changes depending on
> whether or not "tenk1" has been analyzed yet.  In 9.2 and up,
> it reliably has been, because create_index runs first and that script
> does this:

> create_index.sql:901:vacuum analyze tenk1;        -- ensure we get consistent plans here

> so depending on timing, one of those might have gotten the job done,
> or maybe autovacuum would show up in time to save the day.

> 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 HS standby connected via SR and hot_standby_feedback=on on
the standby. Some plans just change from index(only) scans to sequential
scans, presumably because of the lower xmin horizon changed the
stats. Since there's nothing running on the standby in those cases,
there has to be a pretty damn tiny window here somewhere.

I've wondered whether we could fix that by a) more explicit
vacuum/analyzes b) a function waiting for quiescent state.

Arguably we could just define that being unsupported, but given there's
no testing of recovery but that at all that doesn't seem like a good
idea.

There's also fun in running with vacuum_defer_cleanup_age > 0, but I
don't think there's much chance of supporting that.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: ANALYZE sampling is too good
Next
From: Dimitri Fontaine
Date:
Subject: Re: Extension Templates S03E11