Re: Proposal: Add a callback data parameter to GetNamedDSMSegment

> GetNamedDSA and GetNamedDSHash do not have a need for a callback,
> because there isn't custom initialization logic that can be applied there.

The use case for GetNamedDSHash is:

1. I want to create a dshash
2. I want to make sure that I can preload some initial data into it
before any backend is able to access it

My trivial example for it would be persistent statistics: when I want
to collect some information, save it to disk before shutdown, and on
the next startup, I want to load the previous state before continuing
collecting. pg_track_optimizer seems to do this. There are also
definitely other reasons.

* If I do it with GetNamedDSMSegment, it is doable inside the init
function: the init function is called when GetNamedDSMSegment still
holds a lock
* If I do it with traditional shared memory manually it is again
doable, as I control how I call dshash_create. If the code doesn't
already hold a lock, I take a lock when I call it
* But how can I do it with GetNamedDSHash? Should I take a different
lock manually every time before I call GetNamedDSHash? That means I
also have to store that different lock somewhere, I have to call
GetNamedDSMSegment to get storage for that, and at that point it is
easier to call dshash_create there in the initialization function, and
skip GetNamedDSHash entirely.

The answer might be this, that GetNamedDSHash is only for the simple
use cases, and for anything requiring more control, we have to fall
back to using GetNamedDSMSegment. I was just wondering if it would be
useful to add this functionality to GetNamedDSHash.

> I think this test could be
> made better by checking that the arg data matches some data that
> we expect.

I verified the pointer address because it shouldn't change inside
GetNamedDSHash, but as long as the data is the same it doesn't really
matter, this version also looks good.