Re: [PROPOSAL] Shared Ispell dictionaries
От | Arthur Zakirov |
---|---|
Тема | Re: [PROPOSAL] Shared Ispell dictionaries |
Дата | |
Msg-id | 20180516204230.GA2397@artur-book.localdomain обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] Shared Ispell dictionaries (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PROPOSAL] Shared Ispell dictionaries
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: