Re: [PATCH] Refactoring of LWLock tranches

On Thu, Dec 31, 2015 at 7:42 PM, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com
> wrote:

> 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.
>
>
Thanks.

> 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.
>
>
Let take the decision about old API's, once the new API's got reviewed.
We can either remove old API's or use log message to warn users or
mention them as deprecated in docs.

> doc/src/sgml/xfunc.sgml needs an update on how the new API should be used.
>
>
Agreed, will do it in next version of patch.

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