Skip site navigation (1) Skip section navigation (2)

Re: strange OOM errors with EXECUTE in PL/pgSQL

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tv(at)fuzzy(dot)cz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: strange OOM errors with EXECUTE in PL/pgSQL
Date: 2013-01-15 14:43:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 12/20/2012 4:47 PM, Dimitri Fontaine wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> The reason this fails is that you've got a half-megabyte source string,
>> and each of the 11000 plans that are due to be created from it saves
>> its own copy of the source string.  Hence, 5500 megabytes needed just
>> for source strings.
>> We could possibly fix this by inventing some sort of reference-sharing
>> arrangement (which'd be complicated and fragile) or by not storing the
>> source strings with the plans (which'd deal a serious blow to our
>> ability to provide helpful error messages).  Neither answer seems
>> appealing.
> I don't readily see how complicated and fragile it would be, it looks
> like a hash table of symbols pointing to source strings and a reference
> counting, and each plan would need to reference that symbol. Now maybe
> that's what you call complicated and fragile, and even if not, I'm not
> really sure it would pull its weight. The use case of sending over and
> over again *in a given session* the exact same query string without
> using PREPARE/EXECUTE looks like quite tiny.

That sounds like a bit of overkill to me.

Don't all the plans result as a plan list from a multi-statement query 
string, which was parsed into a query tree "list" and each single query 
tree then planned? I don't think there is any way that a single one of 
those trees (parse or plan) will be free'd separately. If that is true, 
then proper usage of memory contexts would make reference counting 
obsolete, even though all plans refer to the same copy.


Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

In response to


pgsql-hackers by date

Next:From: Kohei KaiGaiDate: 2013-01-15 14:48:47
Subject: Re: recent ALTER whatever .. SET SCHEMA refactoring
Previous:From: Peter EisentrautDate: 2013-01-15 14:25:40
Subject: Re: system administration functions with hardcoded superuser checks

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group