On Thu, May 17, 2018 at 10:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> ... Assuming that we can >> convince ourselves that that much is OK, I don't see why using a >> syscache callback to help ensure that the mappings are blown away in >> an at-least-somewhat-timely fashion is worse than any other approach. > > I think the point you've not addressed is that "syscache callback > occurred" does not equate to "object was dropped". Can the code > survive having this occur at any invalidation point? > (CLOBBER_CACHE_ALWAYS testing would soon expose any fallacy there.)
Well, I'm not advocating for a lack of testing, and CLOBBER_CACHE_ALWAYS testing is a good idea. However, I suspect that calling dsm_detach() from a syscache callback should be fine. Obviously there will be trouble if the surrounding code is still using that mapping, but that would be a bug at some higher level, like using an object without locking it. And there will be trouble if you register an on_dsm_detach callback that does something strange, but the ones that the core code installs (when you use shm_mq, for example) should be safe. And there will be trouble if you're not careful about memory contexts, because someplace you probably need to remember that you detached from that DSM so you don't try to do it again, and you'd better be sure you have the right context selected when updating your data structures. But it all seems pretty solvable. I think. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
