Robert Haas <robertmhaas@gmail.com> writes:
> For what it's worth, my vote is currently for #2. I can't think of
> many interesting to do with dynamic shared memory without having at
> least spinlocks, so I don't think we'd be losing much. #1 seems
> needlessly unfriendly, #3 seems like a lot of work for not much, and
> #4 seems excessive at least as a solution to this particular problem,
> though there may be other arguments for it. What do others think?
I agree with this position. There may be some good reason to drop
--disable-spinlocks altogether in future, but DSM isn't a sufficient
excuse.
> I think we're also going to want to be able to create LWLocks in
> dynamic shared memory: some critical sections won't be short enough or
> safe enough to be protected by spinlocks. At some level this seems
> easy: change LWLockAcquire and friends to accept an LWLock * rather
> than an LWLockId, and similarly change held_lwlocks[] to hold LWLock
> pointers rather than LWLockIds.
I seem to recall that there was some good reason for keeping all the
LWLocks in an array, back when the facility was first designed.
I'm too lazy to research the point right now, but you might want to
go back and look at the archives around when lwlock.c was written.
> creating a large number of new globals that will need to be
> initialized in every new EXEC_BACKEND process seems irritating.
This might've been the good reason, but not sure --- I think LWLocks
predate our Windows support.
In the end, though, that decision was taken before we were concerned
about being able to add new LWLocks on the fly, which is what this is
really about (whether they're stored in DSM or not is a secondary point).
The pressure for that has gotten strong enough that it may be time to
change the tradeoff.
regards, tom lane
