Re: Error handling for ShmemInitStruct and ShmemInitHash
От | Kevin Grittner |
---|---|
Тема | Re: Error handling for ShmemInitStruct and ShmemInitHash |
Дата | |
Msg-id | 4BD7FD070200002500030FC7@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Error handling for ShmemInitStruct and ShmemInitHash (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Error handling for ShmemInitStruct and ShmemInitHash
|
Список | 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 по дате отправления: