On Wed, Aug 23, 2017 at 11:58 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Wed, Aug 23, 2017 at 5:46 PM, Andres Freund <and...@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
Description: GNU Zip compressed data
-- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers