On Thu, Sep 17, 2015 at 12:47 PM, Shulgin, Oleksandr <oleksandr.shul...@zalando.de> wrote: > But if we make the sender backend create the DSM with the response payload, > it suddenly becomes really unclear at which point and who should make the > final detach of that DSM. We're getting back to the problem of > synchronization between these processes all over again.
Yes, some thought is needed here. There's not really a problem if somebody asks for information just once: you could just have the publishing process keep it attached until process exit, and nothing bad would happen. The real problem comes when multiple people ask for information in quick succession: if you detach the old segment too quickly after publishing it, the guy who requested that data might not have attached it yet, and then when he gets around to looking at it, it won't be there. This seems like a pretty solvable problem, though. For example, when somebody asks for information, they store in the main shared segment a pointer to their PGPROC and then they signal the target process, which responds by publishing a dsm_segment_id. When the requesting process has accessed it, or when it errors out or exits, it clears the PGPROC and the dsm_segment_id. The publisher avoids unmapping it until that happens. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers