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

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

> On Fri, Feb 12, 2016 at 1:08 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >> I got a error
> >>
> >> ERROR: XX000: requested tranche is not registered
> >> LOCATION: GetNamedLWLockTranche, lwlock.c:602
> >>
> >> Because the session initialization doesn't finish, then Orafce doesn't
> >> work
> >
> > I am starting to understand - the new design is more strict. The Orafce
> is
> > designed to run without registration shared_preload_libraries (it is
> > possible, but not necessary). But - RequestNamedLWLockTranche is working
> > only for this use case. Then GetNamedLWLockTranche fails, and all other
> are
> > probably consequences because shared memory isn't well initialized. After
> > setting shared_preload_libraries all tests are running. But I cannot do
> it
> > generally.
> >
> > What is your recommendation for this case? So I have not to use named
> locks?
>
> 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. 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?

Orafce is multi release code, and I would not to do significant refactoring
when I have not all necessary features on all supported releases. I
understand to fact, so Orafce uses obsolete design, but cannot to change in
this moment (and I would not it if it possible).

Regards

Pavel

>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>