From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Marti Raudsepp <marti(at)juffo(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Less than ideal error reporting in pg_stat_statements |
Date: | 2015-09-25 18:37:41 |
Message-ID: | CAM3SWZT-noXzLT8-y7K7Gkm-B2aQPuCJEukTJC+Qevm5f14VuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 25, 2015 at 8:51 AM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> I've also been seeing lots of log messages saying "LOG: out of
> memory" on a server that's hosting development databases. I put off
> debugging this until now because it didn't seem to have any adverse
> effects on the system.
>
> The file on my system is currently 5.1GB (!). I don't know how it got
> there -- under normal circumstances we don't have any enormous
> queries, but perhaps our application bugs during development triggered
> that.
It could be explained by legitimate errors during planning, for
example. The query text is still stored.
> 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. It will be
non-trivial, and I'm quite busy right now, so it might take a while. A
short-term remediation is to call pg_stat_statements_reset() on
systems affected like this.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-09-25 18:44:26 | Re: How to get value of 'Param' of the WHERE clause in the FDW? |
Previous Message | Fabien COELHO | 2015-09-25 18:35:45 | Re: Doubt in pgbench TPS number |