Re: [PATCH] Refactoring of LWLock tranches
От | Jesper Pedersen |
---|---|
Тема | Re: [PATCH] Refactoring of LWLock tranches |
Дата | |
Msg-id | 568537E1.4030906@redhat.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Refactoring of LWLock tranches (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [PATCH] Refactoring of LWLock tranches
|
Список | pgsql-hackers |
On 12/31/2015 06:36 AM, Amit Kapila wrote: > Going further on this work, I have written a patch for separating the > tranches for extensions. The basic idea is to expose two new API's, > first to request a new tranche and second to assign a lock from that > tranche. > RequestAddinLWLockTranche(const char *tranche_name, int num_lwlocks) > will be used by extensions to request a new tranche with specified number > of locks, this will be used instead of current API RequestAddinLWLocks(). > We need to remember this information for each extension and then > during startup we need to create separate tranches and still have locks > for extensions in the MainLWLockArray such that the base for each > tranche will point to the locks corresponding to that tranche. As for > each proc/backend, we need to register the tranche separately, the > information of newly formed tranches needs to be passed to backends > via save/restore_backend_variables mechanism for EXEC_BACKEND > builds. > LWLock *LWLockAssignFromTranche(const char *tranche_name) will > assign a lock for the specified tranche. This also ensures that no > more than requested number of LWLocks can be assigned from a > specified tranche. > > Also I have retained NUM_USER_DEFINED_LWLOCKS in > MainLWLockArray so that if any extensions want to assign a LWLock > after startup, it can be used from this pool. The tranche for such locks > will be reported as main. > > This is based on the suggestions by Robert in the mail: > http://www.postgresql.org/message-id/CA+TgmoashjaQeSK1bEm-GGc8OWFyLhvOrH=4KJfvKRFt9YkBWQ@mail.gmail.com > > Thoughts? > +1 for the idea. However, RequestAddinLWLocks and LWLockAssign are used by extensions outside of the main tree, so I think it would be better to deprecate the methods for starters with a log statement. NUM_USER_DEFINED_LWLOCKS aren't enough in many cases, so the existing functionality needs to be maintained during the deprecation period. If extensions needs to upgrade to the new API I think LWLockAssign should be removed. doc/src/sgml/xfunc.sgml needs an update on how the new API should be used. Best regards, Jesper
В списке pgsql-hackers по дате отправления: