Re: Error handling for ShmemInitStruct and ShmemInitHash

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-hackers(at)postgreSQL(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Error handling for ShmemInitStruct and ShmemInitHash
Date: 2010-04-28 14:16:55
Message-ID: 4BD7FD070200002500030FC7@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> none of the other half are printing messages that are more useful
> than "out of shared memory" (which isn't even necessarily
> correct).

I think the messages in the locking area are a bit more useful than
"out of shared memory", but it would be trivial to build the
equivalent message in the ShmemInitHash function, based on the first
parameter.

LockMethodProcLockHash = ShmemInitHash("PROCLOCK hash",
init_table_size,
max_table_size,
&info,
hash_flags);
if (!LockMethodProcLockHash)
elog(FATAL, "could not initialize proclock hash table");

Presumably the ShmemInitHash function could add other information
which would make the message *more* useful. (Perhaps other
parameter information or maybe even the actual *cause* of the
failure.)

> I suggest making these functions throw their own errors rather
> than returning NULL on failure, and removing the redundant error
> reports from the callers that have 'em.

+1 It would be low priority if the return value was currently being
consistently checked for NULL; but since that's not the case we have
to do something, and what you suggest sounds best, long term.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross J. Reedstrom 2010-04-28 14:17:16 Re: Add column if not exists (CINE)
Previous Message Tom Lane 2010-04-28 13:58:15 Re: Add column if not exists (CINE)