Arthur Zakirov <a.zaki...@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