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).
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers