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 CAFj8pRA9rJNBixXpJ9OK=63An1cpCHR6fnVong53oB12sMGoUg@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.
List pgsql-hackers


2016-02-12 17:35 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:


2016-02-12 15:46 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:


2016-02-12 15:43 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> That's very strange.  It looks to me like you did exactly the right
>> thing.  Can you provide any details on how it fails?
>
> Looks like some race conditions is there - but I didn't tested it deeper

Well, OK, so I'm totally willing to work with you to help get this
straightened out, but I'm not really going to go download orafce and
debug it for you on company time.  I'm fairly sure that won't win me
any large awards.

I'll do it - just need to finish some other. I hope so this night I'll know more.

In _PG_init I am creating new tranche by RequestNamedLWLockTranche("orafce", 1);

Immediately when I try to use this lock

shmem_lock = sh_mem->shmem_lock = &(GetNamedLWLockTranche("orafce"))->lock;

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?

Regards

Pavel
 
 

Regards

Pavel

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



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: WIP: SCRAM authentication
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.