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?
regards, tom lane