Re: Less than ideal error reporting in pg_stat_statements - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Less than ideal error reporting in pg_stat_statements
Date
Msg-id CAM3SWZSy1g_9p4y4JANA8gyHXsU-C+rK=-ZHoPXthd47-M=o-Q@mail.gmail.com
Whole thread Raw
In response to Re: Less than ideal error reporting in pg_stat_statements  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On Fri, Sep 25, 2015 at 11:37 AM, Peter Geoghegan <pg@heroku.com> wrote:
>> So, as I understand it: if the system runs low on memory for an
>> extended period, and/or the file grows beyond 1GB (MaxAlloc), garbage
>> collection stops entirely, meaning it starts leaking disk space until
>> a manual intervention.
>
> I don't think that there is much more to discuss here: this is a bug.
> I will try and write a patch to fix it shortly.

I should add that it only leaks disk space at the rate at which new
queries are observed that are not stored within pg_stat_statements
(due to an error originating in the planner or something -- they
remain "sticky" entries). The reason we've not heard far more problem
reports is that it usually never gets out of hand in the first place.

Come to think of it, you'd have to repeatedly have new queries that
are never "unstickied"; if you have substantively the same query as an
error-during-planning "sticky" entry, it will still probably be able
to use that existing entry (it will become "unstickied" by this second
execution of what the fingerprinting logic considers to be the same
query).

In short, you have to have just the right workload to hit the bug.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: upcoming infrastructure changes/OS upgrades on *.postgresql.org
Next
From: Dmitry Chichkov
Date:
Subject: Re: How to get value of 'Param' of the WHERE clause in the FDW?