Re: RFC: replace pg_stat_activity.waiting with something more descriptive

> On Sep 13, 2015, at 5:36 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Sat, Sep 12, 2015 at 8:24 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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