Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-13 6:32 GMT+01:00 Robert Haas <robertmhaas(at)gmail(dot)com>:

> On Sat, Feb 13, 2016 at 12:20 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>