Re: Less than ideal error reporting in pg_stat_statements

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Less than ideal error reporting in pg_stat_statements
Дата
Msg-id CAM3SWZSy1g_9p4y4JANA8gyHXsU-C+rK=-ZHoPXthd47-M=o-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Less than ideal error reporting in pg_stat_statements  (Peter Geoghegan <pg@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: upcoming infrastructure changes/OS upgrades on *.postgresql.org
Следующее
От: Dmitry Chichkov
Дата:
Сообщение: Re: How to get value of 'Param' of the WHERE clause in the FDW?