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

Re: [HACKERS] bug in GUC

From: Thomas Hallgren <thhal(at)mailblocks(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [HACKERS] bug in GUC
Date: 2004-06-27 18:45:40
Message-ID: 40DF15D4.30300@mailblocks.com (view raw or flat)
Thread:
Lists: pgsql-docspgsql-hackerspgsql-patches
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> 
> ... We don't want to elog(ERROR) partway through that
> process.  Especially not in the postmaster, where elog(ERROR) is
> tantamount to elog(FATAL).  (But of course the postmaster shouldn't ever
> run out of memory anyway...)
> 
> It's possible that this should all be rethought, but it would be a much
> more wide-ranging change than we've been discussing.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
> 

Here's a patch dealing with the unchecked mallocs and strdups in guc.c. 
Rather than mixing in palloc and TopMemoryContext into the code (would 
be rather messy given that most allocs actually falls into the category 
of not always being permitted to do elog(ERROR/FATAL)), I added a couple 
of simple static functions for guc_alloc, guc_realloc, and guc_strdup 
that are used throughout the guc.c file.

Kind regards,

Thomas Hallgren

Attachment: patch.txt
Description: text/plain (10.9 KB)

In response to

Responses

pgsql-docs by date

Next:From: Alvaro HerreraDate: 2004-06-28 03:07:39
Subject: Bug in docs www
Previous:From: Tom LaneDate: 2004-06-24 17:29:13
Subject: Re: bug in GUC

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2004-06-28 01:45:53
Subject: Re: Fixing pg_dump
Previous:From: Peter EisentrautDate: 2004-06-27 14:56:32
Subject: Re: Custom type with width specifier

pgsql-patches by date

Next:From: Andrew DunstanDate: 2004-06-27 20:58:02
Subject: Re: plperl patch
Previous:From: Andrew DunstanDate: 2004-06-27 14:14:49
Subject: plperl patch

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