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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.
Дата
Msg-id CAFj8pRAEgK788EmxCV7=eNYjA0wFAY75gTGV6yPueW7vg6TT0w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers


2016-02-12 10:37 GMT+01:00 Amit Kapila <amit.kapila16@gmail.com>:
On Fri, Feb 12, 2016 at 2:03 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:


There will be necessary more changes than this. Orafce has some parts based on lw locks. I am able to compile it without any issue. But the lock mechanism is broken now - so impact on extensions will be higher. Have to do some research.

With last commit I am able to compile orafce without warnings, but installcheck is broken. It can be bug in orafce, but this code worked last 7 years.


One question regarding your latest commit in orafce:

- RequestAddinShmemSpace(SHMEMMSGSZ);
+#if PG_VERSION_NUM >= 90600
+
+ RequestNamedLWLockTranche("orafce", 1);
+
+#else
+
RequestAddinLWLocks(1);
+#endif
+
+ RequestAddinShmemSpace(SHMEMMSGSZ);
+
 

It seems you have moved request for shared memory
(RequestAddinShmemSpace()) after requesting locks, any reason
for same?

no, it is only moved after lock request

Pavel
 

You don't need to change the request for shared memory.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: GinPageIs* don't actually return a boolean
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Refactoring of LWLock tranches