Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-05-19 11:25:04 -0400, Tom Lane wrote:
>> No, we'd have two independent entries, each with its own correct refcount.
>> When the refcount on the no-longer-linked-in-the-hashtable entry goes to
>> zero, it'd be leaked, same as it's always been. (The refcount presumably
>> corresponds to someone holding a direct pointer to the Relation struct,
>> which is what they'd use to decrement the refcount.)
> The problem is that only one of these entries will get properly handled
> by cache invalidation.
I don't think that's a problem; if the old entry is still referenced,
presumably the holder of the reference is also holding a lock sufficient
to prevent any problematic schema changes.
> I wonder if the correct thing wouldn't be to
> return the entry already in the cache. But that'd not be trivial to do
> either, without the potential to return a invalid entry :(
The one we just finished computing is presumably "newer" in some sense,
otherwise I would've done it like that. In particular, if the older
entry is no longer rd_isvalid, it'd definitely be unsafe to return.
>> One would hope those are the only ones that get opened during relcache
>> load ;-)
> I thought about it for a while and I wonder if that's necessarily
> correct. If somebody registers a relcache invalidation callback that
> could happen when invalidations are processed somewhere while rebuilding
> a entry?
Cache invalidation callbacks shouldn't do anything that would involve
opening non-system relations, IMO.
regards, tom lane