> On Sep 13, 2015, at 5:36 AM, Robert Haas <robertmh...@gmail.com> wrote: > > 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?
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 <http://www.postgrespro.com/> The Russian Postgres Company
