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

From Tom Lane
Subject Re: Less than ideal error reporting in pg_stat_statements
Date
Msg-id 32132.1444000256@sss.pgh.pa.us
Whole thread Raw
In response to Re: Less than ideal error reporting in pg_stat_statements  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Less than ideal error reporting in pg_stat_statements  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List 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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Less than ideal error reporting in pg_stat_statements
Next
From: Peter Geoghegan
Date:
Subject: Re: Less than ideal error reporting in pg_stat_statements