Re: Fast DSM segments

On Mon, Jul 27, 2020 at 2:45 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> Here's a new version, using the name min_dynamic_shared_memory, which
> sounds better to me. Any objections? I also fixed the GUC's maximum
> setting so that it's sure to fit in size_t.

I pushed it like that. Happy to rename the GUC if someone has a better idea.

I don't really love the way dsm_create()'s code flows, but I didn't
see another way to do this within the existing constraints. I think
it'd be nice to rewrite this thing to get rid of the random
number-based handles that are directly convertible to key_t/pathname,
and instead use something holding {slot number, generation number}.
Then you could improve that code flow and get rid of several cases of
linear array scans under an exclusive lock. The underlying
key_t/pathname would live in the slot. You'd need a new way to find
the control segment itself after a restart, where
dsm_cleanup_using_control_segment() cleans up after the previous
incarnation, but I think that just requires putting the key_t/pathname
directly in PGShmemHeader, instead of a new {slot number, generation
number} style handle. Or maybe a separate mapped file opened by well
known pathname, or something like that.