On Sun, Sep 13, 2015 at 8:06 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.
>
Won't this new API introduce another failure mode which is collision
of tranche name? Will it give the error for collision during Request
call or during shared_memory create?
I understand that such an API could simplify the maintainance of tranche,
but won't it be slightly less user friendly, in particular due to additional
requirement of providing name of tranche which extensions user might or
might not understand the meaning of.
> 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.
>
I think same has to be done for tranches outside MainLWLockArray like WAL
or ReplicationOrigin?
> 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.
>
So will this also require changes in the way extensions assigns the
locks?
Now they call LWLockAssign() during shared memory initialization, so
will that needs change?
