| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | 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:55:52 |
| Message-ID: | CAM3SWZR5KCC5Mxo=yHodc8Qd++R96acNJ05Yh1Egq3TKm5a2Yg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 22, 2015 at 6:01 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> I'm doubtful that this had anything to do with MaxAllocSize. You'd
> certainly need a lot of bloat to be affected by that in any way. I
> wonder how high pg_stat_statements.max was set to on this system, and
> how long each query text was on average.
To clarify: I think it probably starts off not having much to do with
MaxAllocSize. However, it might well be the case that transient memory
pressure results in the problematic code path hitting the MaxAllocSize
imitation. So it starts with malloc() returning NULL, which
temporarily blocks garbage collection, but in bad cases the
MaxAllocSize limitation becomes a permanent barrier to performing a
garbage collection (without a manual intervention).
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stefan Kaltenbrunner | 2015-09-25 19:13:17 | Re: upcoming infrastructure changes/OS upgrades on *.postgresql.org |
| Previous Message | Tom Lane | 2015-09-25 18:54:58 | Re: How to get value of 'Param' of the WHERE clause in the FDW? |