From: | Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PROPOSAL] Shared Ispell dictionaries |
Date: | 2018-05-16 11:36:33 |
Message-ID: | 20180516113631.GA29544@zakirov.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)zakirov(at)postgrespro(dot)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
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-ispell-memory-handling-v14.patch | text/plain | 1.2 KB |
0002-Change-tmplinit-argument-v14.patch | text/plain | 12.5 KB |
0003-Retreive-shared-location-for-dict-v14.patch | text/plain | 16.5 KB |
0004-Store-ispell-in-shared-location-v14.patch | text/plain | 89.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-05-16 11:59:23 | Re: Postgres 11 release notes |
Previous Message | Heikki Linnakangas | 2018-05-16 10:50:04 | Re: Postgres 11 release notes |