Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, May 17, 2018 at 10:18 AM, Tom Lane <tgl@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.
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.
regards, tom lane