> On Sep 13, 2015, at 5:36 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Sat, Sep 12, 2015 at 8:24 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> 1. Modify the tranche mechanism so that information about LWLocks
>> can be tracked easily.  For this already there is some discussion, ideas
>> and initial patch is floated in this thread and there doesn't seem to be
>> much
>> conflicts, so we can write the patch for it.  I am planning to write or
>> modify
>> the existing patch unless you, IIdus or anyone has objections or want to
>> write it, please let me know to avoid duplication of work.
> What I'd like to see happen here is two new API calls.  During the
> early initialization (before shared memory sizing, and during
> process_shared_preload_libraries), backends in either the core code or
> a loadable module can call RequestLWLockTranche(char *, int) to
> request a tranche with the given name and number of locks.  Then, when
> shared memory is created, the core code creates a tranche which is
> part of MainLWLockArray.  The base of the tranche points to the first
> lock in that tranche, and the tranche is automatically registered for
> all subsequent backends.  In EXEC_BACKEND builds, this requires
> stashing the LWLockTranche and the name to which it points in shared
> memory somewhere, so that exec'd backends can look at shared memory
> and redo the registration.  In non-EXEC_BACKEND builds the values can
> just be inherited via fork.  Then, we add a second API call
> LookupLWTrancheByName(char *) which does just that.  This gets used to
> initialize backend-private pointers to the various tranches.
> Besides splitting apart the main tranche into a bunch of tranches with
> individual names so that we can identify lwlocks easily, this approach
> makes sure that the number of locks requested by an extension matches
> the number it actually gets.  Today, frustratingly, an extension that
> requests one number of locks and uses another may work or fail
> unpredictably depending on what other extensions are loaded and what
> they do.  This would eliinate that nuisance: the new APIs would
> obsolete RequestAddinLWLocks, which I would propose to remove.
> Thoughts?

This is pretty much the same that my patch does. There is
two API calls (for a size determination and a tranche creation), except
MainLWLockArray is used only for individual LWLocks.

Also I suggest to keep RequestAddinLWLocks for backward compatibility.

Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com <http://www.postgrespro.com/>
The Russian Postgres Company

Reply via email to