From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
Subject: shm_toc_lookup API
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9696.1496675981.1@sss.pgh.pa.us>
Date: Mon, 05 Jun 2017 11:19:41 -0400
Message-ID: <9697.1496675981@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

shm_toc_lookup() returns NULL if it fails to find the desired key.
Out of the 30 or so call sites, there is exactly one that has any
use for that.  Some of the rest have Asserts that they get back
a non-null result, but the majority just blithely dereference the
pointer.  I do not find this cool at all; given that we're accessing
a shared data structure, we should assign more than zero probability
to the idea that we might not find what we expect to find when we
expect to find it.

I think that shm_toc_lookup() ought to be made to throw elog(ERROR) on an
unexpected failure.  To satisfy the one caller that doesn't want an error,
we could either add a "bool noError" parameter to it, or split it into two
functions shm_toc_lookup() and shm_toc_lookup_noerror().  The latter would
require touching less code, but the former is probably more like what we'd
have had if this were designed more carefully to begin with.

Any preferences?

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers