Re: fix a bogus line in dynahash.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-patches(at)postgresql(dot)org
Subject: Re: fix a bogus line in dynahash.c
Date: 2005-05-25 03:15:29
Message-ID: 7825.1116990929@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Neil Conway <neilc(at)samurai(dot)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

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Qingqing Zhou 2005-05-25 03:20:43 Re: fix a bogus line in dynahash.c
Previous Message Tom Lane 2005-05-25 03:08:36 Re: [PATCH] pg_autovacuum commandline password hiding.