> > > 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
v4-0001-Implement-a-DSA-for-LWLock-tranche-names.patch
Description: Binary data
