On Thu, May 17, 2018 at 1:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, May 17, 2018 at 10:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 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. > > No, you're clearly not getting the point. You could have an absolutely > airtight exclusive lock of any description whatsoever, and that would > provide no guarantee at all that you don't get a cache flush callback. > It's only a cache, not a catalog, and it can get flushed for any reason > or no reason. (That's why we have pin counts on catcache and relcache > entries, rather than assuming that locking the corresponding object is > enough.) So I think it's highly likely that unmapping in a syscache > callback is going to lead quickly to SIGSEGV. The only way it would not > is if we keep the shared dictionary mapped only in short straight-line > code segments that never do any other catalog accesses ... which seems > awkward, inefficient, and error-prone.
Yeah, that's true, but again, you can work around that problem. A DSM mapping is fundamentally not that different from a backend-private memory allocation. If you can avoid freeing memory while you're referencing it -- as the catcache and the syscache clearly do -- you can avoid it here, too. > Do we actually need to worry about unmapping promptly on DROP TEXT > DICTIONARY? It seems like the only downside of not doing that is that > we'd leak some address space until process exit. If you were thrashing > dictionaries at some unreasonable rate on a 32-bit host, you might > eventually run some sessions out of address space; but that doesn't seem > like a situation that's so common that we need fragile coding to avoid it. I'm not sure what the situation is here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
