On Wed, Aug 23, 2017 at 11:58 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, Aug 23, 2017 at 5:46 PM, Andres Freund <andres@anarazel.de> wrote:
>> Notes for possible followup commits of the dshash API:
>> - nontrivial portions of dsahash are essentially critical sections lest
>> dynamic shared memory is leaked. Should we, short term, introduce
>> actual critical section markers to make that more obvious? Should we,
>> longer term, make this more failsafe / easier to use, by
>> extending/emulating memory contexts for dsa memory?
>
> Hmm. I will look into this.
Yeah, dshash_create() leaks the control object if the later allocation
of the initial hash table array raises an error. I think that should
be fixed -- please see 0001 in the new patch set attached.
The other two places where shared memory is allocated are resize() and
insert_into_bucket(), and both of those seem exception-safe to me: if
dsa_allocate() elogs then nothing is changed, and the code after that
point is no-throw. Am I missing something?
>> - SharedRecordTypmodRegistryInit() is called from GetSessionDsmHandle()
>> which calls EnsureCurrentSession(), but
>> SharedRecordTypmodRegistryInit() does so again - sprinkling those
>> around liberally seems like it could hide bugs.
>
> Yeah. Will look into this.
One idea is to run InitializeSession() in InitPostgres() instead, so
that CurrentSession is initialized at startup, but initially empty.
See attached. (I realised that that terminology is a bit like a large
volume called FRENCH CUISINE which turns out to have just one recipe
for an omelette in it, but you have to start somewhere...) Better
ideas?
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers