On Fri, Dec 20, 2013 at 2:33 PM, Andres Freund <andres@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