On Fri, Feb 12, 2016 at 1:08 PM, Pavel Stehule <pavel.steh...@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.

Of course, backward compatibility makes this a bit harder, but you
could do something like:

#if old-version
#define getlock(sh_mem) sh_mem->shmem_lock         /* shmem_lock is an
LWLockId */
#define getlock(sh_mem) &sh_mem->shmem_lock      /* shmem_lock is an LWLock */

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to