2016-02-13 6:32 GMT+01:00 Robert Haas <robertmh...@gmail.com>: > On Sat, Feb 13, 2016 at 12:20 AM, Pavel Stehule <pavel.steh...@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. >
The compatibility layer can be great. Or the some simple API that allows to use lock without hard code refactoring. Regards Pavel > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
