Re: Less than ideal error reporting in pg_stat_statements
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Peter Geoghegan <pg@heroku.com>, Jim Nasby <Jim.Nasby@bluetreble.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2015-10-04T23:10:56Z
Lists: pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes: > Sorry, I'm a bit late to this party. Does what you have committed mean > people are less likely to see "Out of Memory" coming from > pg_stat_statements? If not, what can be done about them short of a > restart? And what bad effects follow from an event generating them? The main thing we've done that will alleviate that is increase the size of query text file that the garbage-collection routine can cope with from MaxAllocSize (1GB) to MaxAllocHugeSize (at least 2GB, lots more on 64bit machines, though on 32-bit you probably can't get to 2GB anyway ...). Also, what will now happen if you do get an out-of-memory is that the code will discard stored query texts and truncate the file, so that the problem doesn't recur (at least not till you build up a new set of stored query texts). At this point you still have statistics, but they can only be identified by query ID since the text has been forgotten. I'm not sure how useful that situation really is ... > The docs seem to be quite silent on these points. The docs probably ought to describe this situation and recommend reducing pg_stat_statements.max if you want to preserve query texts. regards, tom lane
Commits
-
Be more wary about 32-bit integer overflow in pg_stat_statements.
- c67c2e2a2939 16.0 landed
- dd414bf4e047 10.22 landed
- 82ebc70d1c7f 15.0 landed
- 6b67db10c366 13.8 landed
- 6608a4305636 12.12 landed
- 17fd203b414e 14.5 landed
- 06f6a07ba465 11.17 landed