On 2014-05-19 13:45:15 -0400, Tom Lane wrote:
> 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.
Except if it's during ddl itself... But we'd probably seen problems by
now if there aactually probem.
> > 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.
I think that's unneccessarily restrictive. There's good reasons to build
caches ontop the relcache that also have to visit user defined
relations. Imagine the configuration tables of a replication solution
for example. Since there's no builtin, integrated, way to add data to
relcache entries that's pretty much the only choice.
It's probably best to avoid these problems by simply setting an
->invalid flag or something, but I can imagine cases where that's not
the best strategy.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services