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

From Jim Nasby
Subject Re: Less than ideal error reporting in pg_stat_statements
Date
Msg-id 5626BCF5.1090303@BlueTreble.com
Whole thread Raw
In response to Re: Less than ideal error reporting in pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 10/4/15 6:10 PM, Tom Lane wrote:
> 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 ...).

FWIW, I've verified on $CLIENT's system that this works as Tom 
described. The truncation happened somewhere a bit north of 3GB, which 
seems odd as this is a 64 bit system. But at least there were no OOM errors.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: a raft of parallelism-related bug fixes
Next
From: Jim Nasby
Date:
Subject: Re: [PATCH] Typos in comments