> 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.
