pgsql: Change the way that LWLocks for extensions are allocated.

From: Robert Haas <rhaas(at)postgresql(dot)org>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Change the way that LWLocks for extensions are allocated.
Date: 2016-02-04 21:43:14
Message-ID: E1aRRgI-00022x-UD@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-committers pgsql-hackers

Change the way that LWLocks for extensions are allocated.

The previous RequestAddinLWLocks() method had several disadvantages.
First, the locks would be in the main tranche; we've recently decided
that it's useful for LWLocks used for separate purposes to have
separate tranche IDs. Second, there wasn't any correlation between
what code called RequestAddinLWLocks() and what code called
LWLockAssign(); when multiple modules are in use, it could become
quite difficult to troubleshoot problems where LWLockAssign() ran out
of locks. To fix, create a concept of named LWLock tranches which
can be used either by extension or by core code.

Amit Kapila and Robert Haas

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/c1772ad9225641c921545b35c84ee478c326b95e

Modified Files
--------------
contrib/pg_stat_statements/pg_stat_statements.c | 4 +-
doc/src/sgml/xfunc.sgml | 9 +-
src/backend/postmaster/postmaster.c | 6 +
src/backend/storage/lmgr/lwlock.c | 212 ++++++++++++++++++++----
src/include/pg_config_manual.h | 5 -
src/include/storage/lwlock.h | 22 ++-
src/tools/pgindent/typedefs.list | 2 +
7 files changed, 210 insertions(+), 50 deletions(-)

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2016-02-04 22:18:03 pgsql: Add some additional core functions to support join pushdown for
Previous Message Tom Lane 2016-02-04 18:59:05 pgsql: Simplify syntax diagram for REINDEX.

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-02-04 21:47:19 Re: [PATCH] Refactoring of LWLock tranches
Previous Message Andres Freund 2016-02-04 21:42:32 Re: checkpoints after database start/immediate checkpoints