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

From: Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "aekorotkov(at)gmail(dot)com" <aekorotkov(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date: 2015-09-13 15:09:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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: <>
The Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2015-09-13 15:29:00 Re: One question about security label command
Previous Message Stephen Frost 2015-09-13 14:56:05 Re: [DOCS] Missing COMMENT ON POLICY