Re: add function for creating/attaching hash table in DSM registry

On Fri, Jun 13, 2025 at 08:31:22PM +0530, Rahila Syed wrote:
> I am considering whether it would be better to avoid creating another DSM
> segment to track the DSA handle. Would it make more sense to track the
> DSAs in a separate dshash registry similar to DSM segments?

I don't know if it's better to manage 3 dshash tables than to manage 1 with
special entries for DSAs/dshash tables.  There might be some small
trade-offs with each approach, but I haven't thought of anything too
worrisome...

> +               /* Attach to existing DSA. */
> +               dsa = dsa_attach(state->dsah);
> +               dsa_pin_mapping(dsa);
> +
> +               *found = true;
> +       }
> 
> Should this also consider the case where dsa is already mapped, to avoid
> the error on attaching to the DSA twice? IIUC, that would require calling
> dsa equivalent of dsm_find_mapping().

I wanted to find a way to do this, but AFAICT you can't.  DSAs and dshash
tables are returned in backend-local memory, so if you lose that pointer, I
don't think there's a totally safe way to recover it.  For now, I've
documented that GetNamedDSA()/GetNamedDSMHash() should only be called for a
given DSA/dshash once in each backend.

One other thing we could do is add a dsa_is_attached() function and then
ERROR if you try to reattach an already-attached DSA/dshash.  I've done
this in the attached patch.

-- 
nathan