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

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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company