Re: [PROPOSAL] Shared Ispell dictionaries
От | Arthur Zakirov |
---|---|
Тема | Re: [PROPOSAL] Shared Ispell dictionaries |
Дата | |
Msg-id | 20180516113631.GA29544@zakirov.localdomain обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] Shared Ispell dictionaries (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PROPOSAL] Shared Ispell dictionaries
Re: [PROPOSAL] Shared Ispell dictionaries |
Список | pgsql-hackers |
Hello, On Tue, May 15, 2018 at 05:02:43PM -0400, Robert Haas wrote: > On Tue, Mar 27, 2018 at 8:19 AM, Arthur Zakirov > <a.zakirov@postgrespro.ru> wrote: > > Yes, there is dsm_pin_mapping() for this. But it is necessary to keep a > > segment even if there are no attached processes. From 0003: > > > > + /* Remain attached until end of postmaster */ > > + dsm_pin_segment(seg); > > + /* Remain attached until end of session */ > > + dsm_pin_mapping(seg); > > I don't quite understand the problem you're trying to solve here, but: > > 1. Unless dsm_pin_segment() is called, a DSM segment will > automatically be removed when there are no remaining mappings. > > 2. Unless dsm_pin_mapping() is called, a DSM segment will be unmapped > when the currently-in-scope resource owner is cleaned up, like at the > end of the query. If it is called, then the mapping will stick around > until the backend exits. I tried to solve the case when DSM segment remains mapped even a dictionary was dropped. It may happen in the following situation: Backend 1: =# select ts_lexize('english_shared', 'test'); -- The dictionary is loaded into DSM, the segment and the mapping is pinned ... -- Call ts_lexize() from backend 2 below =# drop text search dictionary english_shared; -- The segment and the mapping is unpinned, see ts_dict_shmem_release() Backend 2: =# select ts_lexize('english_shared', 'test'); -- The dictionary got from DSM, the mapping is pinned ... -- The dictionary was dropped by backend 1, but the mapping still is pinned As you can see the DSM still is pinned by backend 2. Later I fixed it by checking do we need to unping segments. In the current version of the patch do_ts_dict_shmem_release() is called in lookup_ts_dictionary_cache(). It unpins segments if text search cache was invalidated. It unpins all segments, but I think it is ok since text search changes should be infrequent. > If you pin the mapping or the segment and later no longer want it > pinned, there are dsm_unpin_mapping() and dsm_unpin_segment() > functions available, too. So it seems like what you might want to do > is pin the segment when it's created, and then unpin it if it's > stale/obsolete. The latter won't remove it immediately, but will once > all the mappings are gone. Yes, dsm_unpin_mapping() and dsm_unpin_segment() will be called when the dictionary is dropped or altered in the current version of the patch. I descriped the approach above. 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. I hope the description is clear. I attached the rebased patch. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: