Re: RFC: replace pg_stat_activity.waiting with something more descriptive - Mailing list pgsql-hackers

From Ildus Kurbangaliev
Subject Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date
Msg-id 04A62A45-A281-4C3B-856F-4DAEAB76F2F4@postgrespro.ru
Whole thread Raw
In response to Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

On Sep 13, 2015, at 5:36 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Sat, Sep 12, 2015 at 8:24 AM, Amit Kapila <amit.kapila16@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
The Russian Postgres Company

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [DOCS] Missing COMMENT ON POLICY
Next
From: Kouhei Kaigai
Date:
Subject: Re: One question about security label command