Re: Why the buildfarm is all pink

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why the buildfarm is all pink
Date: 2013-12-11 15:07:19
Message-ID: 15550.1386774439@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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 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.

The case in create_index does a "vacuum analyze tenk1" and expects
to get an index-only scan in the very next SQL command. So any delay
in considering the table all-visible could break that test. I'm not
sure if that's what you're talking about though. We could easily
create some more delay for that case, for instance by moving the
vacuum step to copy.sql as I was idly speculating about upthread.
Do you remember offhand where the failures are?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ktm@rice.edu 2013-12-11 15:14:17 Re: In-Memory Columnar Store
Previous Message MauMau 2013-12-11 15:01:04 Re: [bug fix] pg_ctl always uses the same event source