| From: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
|---|---|
| To: | pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: fix a bogus line in dynahash.c |
| Date: | 2005-05-25 03:06:19 |
| Message-ID: | d70q77$21aq$1@news.hub.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
"Neil Conway" <neilc(at)samurai(dot)com>writes
> Well, element_alloc() uses the hash table's alloc function pointer. In
> theory, that could be malloc() or anything else, although I notice this
> abstraction is not consistently maintained (e.g. dir_realloc assumes
> pfree() is sufficient to free an allocation).
>
Yes, in theory it could do so. But in fact element_alloc() uses
DynaHashAlloc() for ordinary hash table or uses ShmemAlloc() for shared
memory case. The problem is that both of these could elog(ERROR) themselves.
> I think it would be a good idea to change dynahash.c to assume that the
> hash table's allocation function will elog(ERROR) on out-of-memory,
DynaHashAlloc() looks like this. ShmemAlloc() just elog(WARNING), we could
revise it ... but if you do so, how to rewrite
if (!hash_search(HASH_ENTER)) /* for example: RememberFsyncRequest() */
elog(FATAL/PANIC);
Use critical_section?
Regards,
Qingqing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Conway | 2005-05-25 03:07:52 | Re: fix a bogus line in dynahash.c |
| Previous Message | Tom Lane | 2005-05-25 02:59:15 | Re: fix a bogus line in dynahash.c |