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 further
> would be "fixing" anything. The other change would also mainly just
> sweep the issue under the rug, if there is any issue and it's not
> just that we're overloading underpowered buildfarm machines. (Maybe a
> better fix would be to reduce MAX_CONNECTIONS for the tests on these
> machines?)

I agree that increasing the limit further is not a good solution.

> 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. This
> makes me think that somebody simplified away some logic we maybe
> should have kept. But if we're going to leave it like this, we could
> replace the DBWriteRequest data structure with a simple OID list and
> save a fair amount of code.

Really? Which part of the code is dead? I see pgstat_recv_inquiry() is
updating the request_time after receiving the inquiry, and
pgstat_db_requested() is looking at it when writing the files.

If we can simplify the code by keeping just OIDs, let's do that. I think
the main reason why we haven't done that in 187492b6 was to keep as much
of the existing logic (and maybe change it in a separate patch).


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to