On Sat, Feb 13, 2016 at 12:20 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> Hmm. So orafce is actually benefiting from the 3-lwlock slop that was
>> built into the old system: if one of those original 3 locks was
>> as-yet-unclaimed, orafce grabs it when it initializes. The new system
>> hasn't got that slop, and rather deliberately so. But that means that
>> the trick that worked before no longer works.
>>
>> It looks to me like the easiest thing to do would be to change the
>> definition of sh_memory so that instead of containing an LWLockId, it
>> contains an LWLock and a tranche ID. Then the first process to do
>> ShmemInitHash() can call LWLockNewTrancheId() and LWLockInitialize().
>> Every process, first or not, registers the tranche. Then you don't
>> need GetNamedLWLockTranche(). I think the problem right now is that
>> you can get the shared memory but fail to get the LWLock, and then you
>> have problems... if you put the LWLock in sh_memory, though, that
>> can't happen.
>
>
> The Orafce design is based on old style of shared memory usage. It hasn't
> own segment, and then the pointers are compatible between separate
> processes.
I'm not proposing that you switch to DSM. There's no real benefit to
that here. I'm just proposing that (at least in 9.5 and up) you put
the actual LWLock in the chunk of shared memory that you allocate,
rather than just an LWLockId/LWLock *.
> Using new style needs significant refactoring - and I would to
> wait to end of support 9.3. Same situation is with LWLocks - I should to
> share locks with Postmaster and doesn't create own tranche.
>
> In previous design I was able to increase number of Postmaster locks, and
> later, I can take one Postmaster lock. Is it possible?
Not unless we change something.
The actual code changes for what I proposed are not all that large.
But it is a certain amount of work and complexity that I understand is
not appealing to you.
We could back out these changes or invent some kind of backward
compatibility layer. I don't like that very much, but it could be
done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company