Re: Why the buildfarm is all pink

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Why the buildfarm is all pink
Дата
Msg-id 20131211111206.GB1721@awork2.anarazel.de
обсуждение исходный текст
Ответ на Why the buildfarm is all pink  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Why the buildfarm is all pink
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: ANALYZE sampling is too good
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Extension Templates S03E11