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 CAFj8pRAvKaAruWhTCn43_eBPrk5+rwa-9dZSYg+A1wVvVYT4-A@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-04-12 14:51 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:
On Tue, Apr 12, 2016 at 4:18 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> If there will be simple way, how to fix it, then I'll fix my extensions. But
> new API is working only when the extension has own share memory segment. For
> some complex extensions like Orafce it means expensive refactoring.
>
> What is worst, this refactoring is difficult now, because I support older
> versions when I have not private shared segments.

You don't need a separate shared memory segment.  You might want to
have a look at what we did for pldebugger:

http://git.postgresql.org/gitweb/?p=pldebugger.git;a=commitdiff;h=14c6caf08bb14a7404a8241e47a80ef5f97e451e

I think the problem is similar to the one you are facing with orafce.

I'll try it. Thank you for info

Pavel
 

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

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Choosing parallel_degree
Next
From: Yury Zhuravlev
Date:
Subject: Re: Lets (not) break all the things. Was: [pgsql-advocacy]9.6 -> 10.0