Alvaro Herrera <[EMAIL PROTECTED]> writes:
> 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?
The issue isn't with startup, but with re-reading postgresql.conf due to
SIGHUP later on. We don't want to elog
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 pallo
On Jun 24, 2004, at 10:45 AM, Thomas Hallgren wrote:
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"?
Perhaps a section regarding proper memory management code in the
backe
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 where not
the first ;-)
So, what you are saying is that there's no need for the functions I
suggested and that a palloc using the TopMemoryContext will guar
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> Rather than clutter the code with the same ereport over and over again (I
> count 12 malloc's in guc.c alone), I'd like something like this:
The larger question is why it contains even one. In general, use of
malloc in the backend is the mark of a n
Rather than clutter the code with the same ereport over and over again (I
count 12 malloc's in guc.c alone), I'd like something like this:
void* malloc_or_fail(int elevel, size_t sz)
{
void* result;
if(sz < 1)
/*
* Make sure we have something that can be passed to free() e
I'll look into that. Thanks for pointing it out.
Kind regards,
Thomas Hallgren
"Alvaro Herrera" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hackers,
>
> I think there a bug in the GUC mechanism. The custom variables patch
> added several malloc() and a strdup() call, and they
Hackers,
I think there a bug in the GUC mechanism. The custom variables patch
added several malloc() and a strdup() call, and they are never checked
for an out of memory condition.
--
Alvaro Herrera ()
"El que vive para el futuro es un iluso, y el que vive para el pasado,
un imbécil" (Luis Adle
