On 03/25/2018 06:18 AM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> On 3/24/18 9:56 PM, Tom Lane wrote:
>>> Also, the scheme for releasing the dictionary DSM during
>>> RemoveTSDictionaryById is uncertain and full of race conditions:
>>> the DROP might roll back later, or someone might come along and
>>> start using the dictionary (causing a fresh DSM load) before the
>>> DROP commits and makes the dictionary invisible to other sessions.
>>> I don't think that either of those are necessarily fatal objections,
>>> but there needs to be some commentary there explaining what happens.
>
>> Actually, I think that's an issue - such race condition might easily
>> leak the shared memory forever (because the new dictionary will get a
>> different OID etc.). It probably is not happening very often, because
>> dictionaries are not dropped very often. But it needs fixing I think.
>
> My thought was (a) the ROLLBACK case is ok, because the next use of
> the dictionary will reload it, and (b) the reload-concurrently-with-
> DROP case is annoying, because indeed it leaks, but the window is small
> and it probably won't be an issue in practice. We would need to be
> sure that the DSM segment goes away at postmaster restart, but given
> that I think it'd be tolerable. Of course it'd be better not to have
> the race, but I see no easy way to prevent it -- do you?
>
Unfortunately no :( For a moment I thought that perhaps we could make it
a responsibility of the last user of the dictionary - set a flag in the
shared memory, and the last user would remove it. But the trouble is how
to decide who's the last one? Even with some simple reference counting,
we probably don't know if that's the really last one.
FWIW this is where the view listing dictionaries loaded into shared
memory would be helpful - you'd at least know there's a dictionary,
wasting memory.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
