> > > With a local hash table, I don't think it's necessary to introduce new
> > > code for managing
> > > a DSA based list of tranche names as is done in v3. We can go back to
> > > storing the shared
> > > trance names in dshash.
> > >
> > > What do you think?
> >
> > My first thought is that a per-backend hash table seems too
> > expensive/complicated for this. Couldn't it just be an array like we have
> > now?
>
> We can, but I was considering simplicity of implementation, and using a
> local hash table is slightly simpler.
>
> That said, since we're dealing with an append-only data structure, a hash
> table is probably more than we need. All we need is index-based lookup,
> so I’ll go with the local array to mirror the shared ( dsa ) array.
Here is v4. We can keep using the local array as the backend local array.
It will already include the tranches registered during postmaster startup,
and it will be updated during tranche name lookup from the dsa based
array. I added a new routine UpdateLocalTrancheName which can be used
in both LWLockRegisterTranche and GetLWTrancheName to append to the
local tranche during both postmaster startup and afterwards.
Also, initially I thought we can get rid of returning the "extension" wait event
name, but it's still possible for an "extension" tranche name to be returned
if LWLockInitialize is called with a tranche_id that was never registered
with LWLockNewTrancheId. We don't prevent that, and I can't see how
we can without changing the LWLockInitialize API, but it is something
that should probably be improved. For now, I added a mention of this
behavior in the documentation. This is existing behavior, so I could
also separate this doc change into a separate patch if it makes more
sense to do so.
--
Sami
