mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove hash_destroy calls in hash_create's failure paths. As noted by

Browse Source 
a Coverity warning, these are risky since the hashtable isn't necessarily
fully set up yet.  They're unnecessary anyway: a deletable hashtable
should be in a memory context that will be cleared following elog(ERROR).
Per report from Martijn van Oosterhout.
This commit is contained in:
Tom Lane 2006-08-14 12:39:55 +00:00
parent f058451871
commit c859294ca2
1 changed files with 1 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/backend/utils/hash/dynahash.c
View File

@ -26,7 +26,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/utils/hash/dynahash.c,v 1.70 2006/07/22 23:04:39 tgl Exp $
* $PostgreSQL: pgsql/src/backend/utils/hash/dynahash.c,v 1.71 2006/08/14 12:39:55 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -392,10 +392,7 @@ hash_create(const char *tabname, long nelem, HASHCTL *info, int flags)
/* Build the hash directory structure */
if (!init_htab(hashp, nelem))
{
hash_destroy(hashp);
elog(ERROR, "failed to initialize hash table");
}
/*
* For a shared hash table, preallocate the requested number of elements.
@ -409,12 +406,9 @@ hash_create(const char *tabname, long nelem, HASHCTL *info, int flags)
nelem < hctl->nelem_alloc)
{
if (!element_alloc(hashp, (int) nelem))
{
hash_destroy(hashp);
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of memory")));
}
}
return hashp;