Date: Thu, 24 Jun 2004 12:55:42 -0400
From: Alvaro Herrera <alvherre@dcc.uchile.cl>
To: Thomas Hallgren <thhal@mailblocks.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: bug in GUC
Message-ID: <20040624165542.GB2761@dcc.uchile.cl>
References: <20040624052712.GA7158@dcc.uchile.cl> <cbe5q2$kpa$1@news.hub.org>
	<13534.1088085728@sss.pgh.pa.us> <cbeplq$2nl6$1@news.hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <cbeplq$2nl6$1@news.hub.org>
User-Agent: Mutt/1.5.5.1i

On Thu, Jun 24, 2004 at 04:45:31PM +0200, Thomas Hallgren wrote:
> Ok, so I'm a newbie. To my defence I'll say that I made an effort to follow
> the style previously used in guc.c. The unchecked mallocs I added were not
> the first ;-)

Apparently Peter thought it was a good idea *not* to use palloc and
friends, and documented it.  The rationale seems to be "we have more
control over out-of-memory conditions", and if you look closely, the
out-of-memory is handled at a lower level than ERROR if it's not
processing interactively.  For example, when reading the config file,
the ereport is DEBUG2.

I'm not sure exactly why this is a good idea.  After all, if the systems
runs out of memory while starting up, what can be expected later?  Not a
lot is going to work.

> So, what you are saying is that there's no need for the functions I
> suggested and that a palloc using the TopMemoryContext will guarantee
> correct behavior on "out of memory"?

IMO yes and yes.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La felicidad no es mañana. La felicidad es ahora"