On Wed, May 16, 2018 at 09:33:46AM -0400, Robert Haas wrote: > > In sum, I think the problem is mostly solved. Backend 2 unpins the > > segment in next ts_lexize() call. But if backend 2 doesn't call > > ts_lexize() (or other TS function) anymore the segment will remain mapped. > > It is the only problem I see for now. > > Maybe you could use CacheRegisterSyscacheCallback to get a callback > when the backend notices that a DROP has occurred.
Yes, it was the first approach. DSM segments was unpinned in InvalidateTSCacheCallBack() in that approach, which is registered using CacheRegisterSyscacheCallback(). I haven't deep knowledge about guts of invalidation callbacks. It seems that there is problem with it. Tom pointed above: > > I'm not sure that I understood the second case correclty. Can cache > > invalidation help in this case? I don't have confident knowledge of cache > > invalidation. It seems to me that InvalidateTSCacheCallBack() should > > release segment after commit. > > "Release after commit" sounds like a pretty dangerous design to me, > because a release necessarily implies some kernel calls, which could > fail. We can't afford to inject steps that might fail into post-commit > cleanup (because it's too late to recover by failing the transaction). > It'd be better to do cleanup while searching for a dictionary to use. But it is possible that I misunderstood his note. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company
