On 2013-10-31 12:21:31 -0400, Robert Haas wrote: > Patch #2, shm-toc-v1.patch, provides a facility for sizing a dynamic > shared memory segment before creation, and for dividing it up into > chunks after it's been created. It therefore serves a function quite > similar to RequestAddinShmemSpace, except of course that there is only > one main shared memory segment created at postmaster startup time, > whereas new dynamic shared memory segments can come into existence on > the fly; and it serves even more conspicuously the function of > ShmemIndex, which enables backends to locate particular data > structures within the shared memory segment. It is however quite a > bit simpler than the ShmemIndex mechanism: we don't need the same > level of extensibility here that we do for the main shared memory > segment, because a new extension need not piggyback on an existing > dynamic shared memory segment, but can create a whole segment of its > own.
So, without the argument of having per-extension dsm segments, I'd say that a purely integer key sucks, because it's hard to manage and debug. This way it's still not too nice, but I don't see a all that good alternative. Comments about shm-toc-v1.patch: Since you're embedding spinlocks in struct shm_toc, this module will be in conflict with platforms that do --disable-spinlocks, since the number of spinlocks essentially needs to be predetermined there. I personally still think the solution to that is getting rid of --disable-spinlocks. I vote for removing all the shm_toc_estimator() knowledge from the header, there seems little reason to expose it that way. That just exposes unneccessary details and makes fixes after releases harder (requiring extensions to recompile). Function call costs hardly can matter, right? Do you assume that lookup speed isn't that important? I have a bit of a hard time imagining that linear search over the keys isn't going to bite us. At the least there should be a comment somewhere documenting that the indented usecase is having a relatively few keys. Wouldn't it make sense to have a function that does the combined job of shm_toc_insert() and shm_toc_allocate()? What's the assumption about the use of the magic in create/attach? Just statically defined things in user code? Ok, cooking now, then I'll have a look at the queue itself, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
