On Sat, Sep 12, 2015 at 8:24 AM, Amit Kapila <amit.kapil...@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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
