On 2014-05-19 11:25:04 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-05-18 14:49:10 -0400, Tom Lane wrote: > >> if (RelationHasReferenceCountZero(oldrel)) > >> RelationDestroyRelation(oldrel, false); > >> else > >> elog(WARNING, "leaking still-referenced duplicate relation"); > > > If that happens we'd essentially have a too low reference count on the > > entry remaining in the relcache. > > 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 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 :( > > I'd consider putting an Assert() in that branch. > > I'm a bit afraid to do that for a condition that the system's never tested > for at all up to now; in any case, a WARNING would be visible in production > whereas an Assert would probably do nothing. Ifentry we see no reports of > this > WARNING for a release cycle or so, maybe asserting would be appropriate. Fair point. > > Perhaps it should also be only allowed for system > > relations? > > 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? > Still concerned about RememberToFreeTupleDescAtEOX, but that's an > independent issue really. Me too and yes. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
