Re: fix a bogus line in dynahash.c
От | Tom Lane |
---|---|
Тема | Re: fix a bogus line in dynahash.c |
Дата | |
Msg-id | 7825.1116990929@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: fix a bogus line in dynahash.c (Neil Conway <neilc@samurai.com>) |
Список | pgsql-patches |
Neil Conway <neilc@samurai.com> writes: > Tom Lane wrote: >> That test is a no-op in the case where hashp->alloc in fact points to >> palloc. But it doesn't always point there --- see shmem_alloc. > Perhaps it would be a net win to change ShmemAlloc() to elog(ERROR) on > out-of-memory? Possibly. I haven't looked through the call sites to make an estimate on whether this would be worthwhile or not. One thing you'd have to look at carefully is whether any of the call sites are inside critical sections --- if so, an elog(ERROR) inside ShmemAlloc would become elog(PANIC), which might be more severe than is warranted. > A fair few of the ShmemAlloc() call sites don't bother to > check the return value anyway, Really? But it wouldn't surprise me that much --- the vast majority of the individual calls are during postmaster initialization, and could not possibly fail unless the initial-shmem-space-request calculation is wrong. The only case that can actually fail on-the-fly is allocation of a new entry in a shared-memory hash table, and we know that case is checked. regards, tom lane
В списке pgsql-patches по дате отправления: