On Fri, Dec 20, 2013 at 2:33 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2013-12-20 14:10:57 -0500, Robert Haas wrote: >> > 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. >> >> Yep. We can either deprecate --disable-spinlocks, or we can add an >> API that is the reverse of S_INIT_LOCK(). > > How is that going to help? Even if we'd deallocate unused spinlocks - > which sure is a good idea when they require persistent resources like > the PGSemaphore based one - the maximum is still going to be there.
Well, we can set the maximum to a bigger number, if that's what we want to do, but I'll admit it's unclear what value would be sufficient. We probably won't have more than one TOC per DSM, and the maximum number of DSMs is capped based on MaxBackends, but it seems likely that many applications of dynamic shared memory will require spinlocks, and I don't think we can plausibly calculate an upper bound there. If we could it would be a big number, and that might just make startup fail anyway. Personally, I don't have a big problem with the idea that if you compile with --disable-spinlocks, some things may just fail, and parallel whatever might be one of those things. We could just bump the "30" in SpinlockSemas to "100", and if you happen to use more than that, too bad for you: it'll fail. But I also don't have a big problem with removing --disable-spinlocks altogether. What do other people think? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
