On Thu, Sep 21, 2017 at 12:59 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Sep 20, 2017 at 5:54 AM, Craig Ringer <craig@2ndquadrant.com> wrote: >> By the way, dsa.c really needs a cross-reference to shm_toc.c and vice >> versa. With a hint as to when each is appropriate. > > /me blinks. > > Aren't those almost-entirely-unrelated facilities?
I think I see what Craig means.
1. A DSM segment works if you know how much space you'll need up front so that you can size it. shm_toc provides a way to exchange pointers into it with other backends in the form of shm_toc keys (perhaps implicitly, in the form of well known keys or a convention like executor node ID -> shm_toc key). Examples: Fixed sized state for parallel-aware executor nodes, and fixed size parallel executor infrastructure.
2. A DSA area is good if you don't know how much space you'll need yet. dsa_pointer provides a way to exchange pointers into it with other backends. Examples: A shared cache, an in-memory database object like Gaddam Sai Ram's graph index extension, variable sized state for parallel-aware executor nodes, the shared record typmod registry stuff.
Perhaps confusingly we also support DSA areas inside DSM segments, there are DSM segments inside DSA areas. We also use DSM segments as a kind of shared resource cleanup mechanism, and don't yet provide an equivalent for DSA. I haven't proposed anything like that because I feel like there may be a better abstraction of reliable scoped cleanup waiting to be discovered (as I think Craig was also getting at).
Well said, and what I would've wanted to say if I could've figured it out well enough to express it.
Hence needing some kind of README or cross reference to help people know which facility/facilities are suitable for their needs... and actually discover them.
(A hint on RequestAddinShmemSpace etc pointing to DSM + DSA would be good too)
