Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
Date
Msg-id CA+TgmoZ5hqpgSOtxnDj5wpANiY3DtW4-8TNTeWRL3RfZ02Q1UA@mail.gmail.com
Whole thread Raw
In response to Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
List pgsql-hackers
On Mon, Jan 19, 2015 at 10:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If that were true I'd agree with you, but it's false on its face.
> A user who is actually examining the statistics might well want to
> know if they're significantly out of date.  A very relevant example
> is that I've always wondered how come, when we see buildfarm failures
> in the "stats" regression test, they always appear in the form of
> output differences that indicate that the session did not see the
> expected stats update --- but there's never a timeout warning printed,
> which indicates that whatever the cause is, it ain't that.

Sure, but nobody who is not a developer is going to care about that.
A typical user who sees "pgstat wait timeout", or doesn't, isn't going
to be able to make anything at all out of that.

> I'd be fine with changing the warning to LOG level rather than
> suppressing it entirely for the specific case of pgstat_vacuum_stat;
> but I do want to distinguish that case, wherein it's fair to conclude
> that obsolete stats aren't too worrisome, from other cases where no
> such conclusion is justified.

But I can live with this compromise.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: "Timmer, Marius"
Date:
Subject: Re: [PATCH] explain sortorder
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: disallow operator "=>" and use it for named parameters