From: Tom Lane <tgl@sss.pgh.pa.us>
To: Arthur Zakirov <a.zakirov@postgrespro.ru>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PROPOSAL] Shared Ispell dictionaries
Date: Sun, 25 Mar 2018 14:28:29 -0400
Message-ID: <15073.1522002509@sss.pgh.pa.us> (raw)
In-Reply-To: <20180325095340.GA1370@arthur.localdomain>
References: <3c7910ba-2a1b-5b73-71c6-d037ba1e89bd@2ndquadrant.com>
<CAKNkYnzWuSV-JoMBPDrWPjomUC4n1QtYd8Yugo9hpJrbtHcALg@mail.gmail.com>
<d4d52484-e269-9d7b-cef5-c1e95a03d9c6@2ndquadrant.com>
<20180319110648.GA32319@zakirov.localdomain>
<2ae9588a-f3cb-777d-1958-c76c22225823@2ndquadrant.com>
<20180320131149.GA12884@zakirov.localdomain>
<ebcb7f9d-eec2-3138-efde-af83b6a0f04f@2ndquadrant.com>
<20180321090050.GA21751@zakirov.localdomain>
<20180322105603.GA23544@zakirov.localdomain>
<28250.1521924996@sss.pgh.pa.us>
<20180325095340.GA1370@arthur.localdomain>
Arthur Zakirov <a.zakirov@postgrespro.ru> writes:
> On Sat, Mar 24, 2018 at 04:56:36PM -0400, Tom Lane wrote:
>> * And that leads us to not particularly need a view telling which
>> dictionaries are loaded, either. It's just an implementation detail
>> that users don't need to worry about.
> If all dictionaries will be shareable then this view could be removed.
> Unfortunately I think it can't help with leaked segments, I didn't find
> a way to iterate dshash entries. That's why pg_ts_shared_dictionaries()
> scans pg_ts_dict table instead of scanning dshash table.
If you're scanning pg_ts_dict, what happens with dictionaries belonging
to other databases? They won't be visible in your local copy of
pg_ts_dict. Between that and the inability to find leaked segments,
I'm not seeing that this has much use-case.
>> (It might work to use
>> the combination of dictionary OID and TID of the dictionary's pg_ts_dict
>> tuple as the lookup key for shared dictionaries. Oh, and have you
>> thought about the possibility of conflicting OIDs in different DBs?
>> Probably the database OID has to be part of the key, as well.)
> Yes unfortunately ALTER TEXT SEARCH DICTIONARY doesn't reload a
> dictionary. TID can help here. I thought about using XID too when I
> started to work on RELOAD command. But I'm not sure that it is a good
> idea, anyway XID isn't needed in current version.
Actually, existing practice is to check both xmin and tid; see for example
where plpgsql checks if a cached function data structure still matches the
pg_proc row, pl_comp.c around line 175 in HEAD. The other PLs do it
similarly I think. I'm not sure offhand just how much that changes the
risks of a false match compared to testing only one of these fields, but
I'd recommend conforming to the way it's done elsewhere.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, a.zakirov@postgrespro.ru, tomas.vondra@2ndquadrant.com, pavel.stehule@gmail.com, andres@anarazel.de, i.kurbangaliev@postgrespro.ru
Subject: Re: [PROPOSAL] Shared Ispell dictionaries
In-Reply-To: <15073.1522002509@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox