Re: [PATCH] Refactoring of LWLock tranches

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: [PATCH] Refactoring of LWLock tranches
Date: 2015-12-31 11:36:00
Message-ID: CAA4eK1KjshwP0dfCQ6CHPnQ_WJQWLEApmfD4z6kUsLtqTuzfzw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Tue, Dec 29, 2015 at 2:26 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> On Wed, Dec 16, 2015 at 12:26 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> >
> >
> > In terms of this project overall, NumLWLocks() now knows about only
> > four categories of stuff: fixed lwlocks, backend locks (proc.c),
> > replication slot locks, and locks needed by extensions. I think it'd
> > probably be fine to move the backend locks into PGPROC directly, and
> > the replication slot locks into ReplicationSlot.
> >
>
> IIdus has written a patch to move backend locks into PGPROC which
> I am reviewing and will do performance tests once he responds to
> my review comments and I have written a patch to move replication
> slot locks into ReplicationSlot which is attached with this mail.
>
>
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?

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

Attachment Content-Type Size
separate_tranche_extensions_v1.patch application/octet-stream 14.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-12-31 11:48:59 Re: [PATCH] Refactoring of LWLock tranches
Previous Message Dilip Kumar 2015-12-31 11:22:50 Re: Relation extension scalability