| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Matt Kelly <mkellycs(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Better way of dealing with pgstat wait timeout during buildfarm runs? |
| Date: | 2015-01-22 07:32:48 |
| Message-ID: | 20150122073248.GA7148@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-01-21 22:43:03 -0500, Matt Kelly wrote:
> >
> > 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.
>
>
> As a user, I wholeheartedly disagree.
Note that that the change we discussed wasn't removing the message. It
was changing the log level from WARNING to LOG. Which means the change
is not going to the client anymore, but still to the server log (perhaps
surprisingly, the likelihood for the latter actually increases).
> I think the warning is incredibly valuable. Along those lines I'd also
> love to see a pg_stat_snapshot_timestamp() for monitoring code to use to
> determine if its using a stale snapshot, as well as helping to smooth
> graphs of the statistics that are based on highly granular snapshotting.
I can see that being useful.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2015-01-22 10:27:39 | [POC] FETCH limited by bytes. |
| Previous Message | Amit Kapila | 2015-01-22 05:30:02 | Re: Parallel Seq Scan |