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.
That warning helped me massively in diagnosing an unhealthy
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
On 25.12.2014 22:28, Tomas Vondra wrote:
On 25.12.2014 21:14, Andres Freund wrote:
That's indeed odd. Seems to have been lost when the statsfile was
split into multiple files. Alvaro, Tomas?
The goal was to keep the logic as close to the original as possible.
IIRC there were pgstat wait
On 21.1.2015 00:38, Michael Paquier wrote:
On Wed, Jan 21, 2015 at 1:08 AM, Tomas Vondra
I've tried to reproduce this on my Raspberry PI 'machine' and it's not
very difficult to trigger this. About 7 out of 10 'make check' runs fail
because of 'pgstat wait timeout'.
All the occurences I've
On Wed, Jan 21, 2015 at 1:08 AM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
On 25.12.2014 22:28, Tomas Vondra wrote:
On 25.12.2014 21:14, Andres Freund wrote:
That's indeed odd. Seems to have been lost when the statsfile was
split into multiple files. Alvaro, Tomas?
The goal was to
On Sat, Dec 27, 2014 at 8:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 27, 2014 at 7:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This would have the effect of transferring all responsibility for
dead-stats-entry cleanup to autovacuum. For
On 12/27/2014 12:16 AM, Alvaro Herrera wrote:
Tom Lane wrote:
The argument that autovac workers need fresher stats than anything else
seems pretty dubious to start with. Why shouldn't we simplify that down
to they use PGSTAT_STAT_INTERVAL like everybody else?
The point of wanting fresher
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 12/27/2014 12:16 AM, Alvaro Herrera wrote:
Tom Lane wrote:
The argument that autovac workers need fresher stats than anything else
seems pretty dubious to start with. Why shouldn't we simplify that down
to they use PGSTAT_STAT_INTERVAL
On Sat, Dec 27, 2014 at 7:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 12/27/2014 12:16 AM, Alvaro Herrera wrote:
Tom Lane wrote:
The argument that autovac workers need fresher stats than anything else
seems pretty dubious to start with. Why
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 27, 2014 at 7:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This would have the effect of transferring all responsibility for
dead-stats-entry cleanup to autovacuum. For ordinary users, I think
that'd be just fine. It might be less fine
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Yeah, I've been getting more annoyed by that too lately. I keep wondering
though whether there's an actual bug underneath that behavior that we're
failing to see.
I think the first thing to do is reconsider usage of
Tom Lane wrote:
The argument that autovac workers need fresher stats than anything else
seems pretty dubious to start with. Why shouldn't we simplify that down
to they use PGSTAT_STAT_INTERVAL like everybody else?
The point of wanting fresher stats than that, eons ago, was to avoid a
worker
Hi,
We quite regularly have buildfarm failures that are caused by 'WARNING:
pgstat wait timeout' at random points during the build. Especially on
some of the ARM buildfarm animals those are really frequent, to the
point that it's hard to know the actual state of the buildfarm without
looking at
Andres Freund and...@2ndquadrant.com writes:
So I think a better way to deal with that warning would be a good
idea. Besides somehow making the mechanism there are two ways to attack
this that I can think of, neither of them awe inspiring:
1) Make that WARNING a LOG message instead. Since
On 2014-12-25 14:36:42 -0500, Tom Lane wrote:
I wonder whether when multiple processes are demanding statsfile updates,
there's some misbehavior that causes them to suck CPU away from the stats
collector and/or convince it that it doesn't need to write anything.
There are odd things in the
On 25.12.2014 20:36, Tom Lane wrote:
Yeah, I've been getting more annoyed by that too lately. I keep
wondering though whether there's an actual bug underneath that
behavior that we're failing to see. PGSTAT_MAX_WAIT_TIME is already
10 seconds; it's hard to credit that increasing it still
Tomas Vondra t...@fuzzy.cz writes:
On 25.12.2014 20:36, Tom Lane wrote:
BTW, I notice that in the current state of pgstat.c, all the logic
for keeping track of request arrival times is dead code, because
nothing is actually looking at DBWriteRequest.request_time.
Really? Which part of the
On 25.12.2014 21:14, Andres Freund wrote:
On 2014-12-25 14:36:42 -0500, Tom Lane wrote:
My guess is that a checkpoint happened at that time. Maybe it'd be a
good idea to make pg_regress start postgres with log_checkpoints
enabled? My guess is that we'd find horrendous 'sync' times.
Tomas Vondra t...@fuzzy.cz writes:
The strange thing is that the split happened ~2 years ago, which is
inconsistent with the sudden increase of this kind of issues. So maybe
something changed on that particular animal (a failing SD card causing
I/O stalls, perhaps)?
I think that hamster has
On 25.12.2014 22:16, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 25.12.2014 20:36, Tom Lane wrote:
BTW, I notice that in the current state of pgstat.c, all the logic
for keeping track of request arrival times is dead code, because
nothing is actually looking at
On 25.12.2014 22:40, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
The strange thing is that the split happened ~2 years ago, which is
inconsistent with the sudden increase of this kind of issues. So maybe
something changed on that particular animal (a failing SD card causing
I/O stalls,
Tomas Vondra t...@fuzzy.cz writes:
On 25.12.2014 22:40, Tom Lane wrote:
I think that hamster has basically got a tin can and string for an I/O
subsystem. It's not real clear to me whether there's actually been an
increase in wait timeout failures recently; somebody would have to
go through
On 26.12.2014 02:59, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 25.12.2014 22:40, Tom Lane wrote:
I think that hamster has basically got a tin can and string for an I/O
subsystem. It's not real clear to me whether there's actually been an
increase in wait timeout failures
On Fri, Dec 26, 2014 at 6:28 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 25.12.2014 21:14, Andres Freund wrote:
On 2014-12-25 14:36:42 -0500, Tom Lane wrote:
My guess is that a checkpoint happened at that time. Maybe it'd be a
good idea to make pg_regress start postgres with log_checkpoints
Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
So I think a better way to deal with that warning would be a good
idea. Besides somehow making the mechanism there are two ways to attack
this that I can think of, neither of them awe inspiring:
1) Make that WARNING a LOG
25 matches
Mail list logo
