Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring. - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring. |
| Date | |
| Msg-id | CAFj8pRBtviDF6G2_gvFrm6UY3RVQxj4jEpa1-8-CVzQHNDPKRw@mail.gmail.com Whole thread Raw |
| In response to | Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring. (Robert Haas <robertmhaas@gmail.com>) |
| Responses |
Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent
LWLock refactoring.
|
| List | pgsql-hackers |
2016-02-13 4:52 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Fri, Feb 12, 2016 at 1:08 PM, Pavel Stehule <pavel.stehule@gmail.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
pgsql-hackers by date: