Re: [PATCH] Refactoring of LWLock tranches - Mailing list pgsql-hackers

From Jesper Pedersen
Subject Re: [PATCH] Refactoring of LWLock tranches
Date
Msg-id 568537E1.4030906@redhat.com
Whole thread Raw
In response to Re: [PATCH] Refactoring of LWLock tranches  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [PATCH] Refactoring of LWLock tranches
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Next
From: Alvaro Herrera
Date:
Subject: 2016-01 Commitfest