Re: fix a bogus line in dynahash.c - Mailing list pgsql-patches

From Tom Lane
Subject Re: fix a bogus line in dynahash.c
Date
Msg-id 7825.1116990929@sss.pgh.pa.us
Whole thread Raw
In response to Re: fix a bogus line in dynahash.c  (Neil Conway <neilc@samurai.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] pg_autovacuum commandline password hiding.
Next
From: Neil Conway
Date:
Subject: Re: [PATCH] pg_autovacuum commandline password hiding.