On Fri, Mar 3, 2017 at 1:43 PM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, some of my collegues found that orafce crashes with > postgresql compliled with dtrace. > > === The cause > > The immediate cause was I think that it just did > LWLockNewTrancheId and forget to do LWLockRegisterTranche. But > this is hardly detectable by a module developer. > > > Typical tracepoint looks like the following. > >> TRACE_POSTGRESQL_LWLOCK_WAIT_DONE(T_NAME(lock), mode); > > Where T_NAME is (LWLockTrancheArray[(lock)->tranche]), as you see > T_NAME assumes that all tranches pointed from lwlocks are > available on the array but the tranches without > LWLockRegisterTranche are not. What is worse this doesn't harm so > much without dtrace (or LWLOCK_STATS or error in LWLockRelease) > . Even if dtrace is activated one or two unregistred tranches > (faultly) have their seat (filled with trash) at the end of the > array with the current code. > > As my understanding there are two ways to use lwlocks in > extension. One is using LWLockNewTrancheId and > LWLockRegisterTanche on shared memory provided by the module. The > other is using RequestNamedLWLockTranche in _PG_init and > GetNamedLWLockTranche to acquire locks provided by postgresql. > > I couldn't find a documentation about lwlock and trance in > extentions, is there any? >
You can read about usage of LWLocks in extensions from below location: https://www.postgresql.org/docs/devel/static/xfunc-c.html#idp86986416 Alternatively, you can check the commit c1772ad9225641c921545b35c84ee478c326b95e to see how it is used in pg_stat_statements. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
