Re: Error handling for ShmemInitStruct and ShmemInitHash - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Error handling for ShmemInitStruct and ShmemInitHash
Date
Msg-id 4BD7FD070200002500030FC7@gw.wicourts.gov
Whole thread Raw
In response to Error handling for ShmemInitStruct and ShmemInitHash  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Error handling for ShmemInitStruct and ShmemInitHash  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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
initializeproclock 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add column if not exists (CINE)
Next
From: "Ross J. Reedstrom"
Date:
Subject: Re: Add column if not exists (CINE)