I wrote:
> Interestingly, the bug can no longer be reproduced in CVS HEAD, because
> pg_database no longer has a trigger. We had better fix it anyway of
> course, since future hash collisions are unpredictable. I'm wondering
> though whether to bother back-patching further than 8.4. Thoughts?
I have been poking at this some more and have confirmed that there
doesn't seem to be a crash risk before 8.4 with respect to the
next-hashtable-scan-entry problem. However, I have also confirmed that
it is possible for the *current* relcache entry to get freed by sinval
reset, because the loop in RelationCacheInitializePhase2 doesn't bother
to increment the entry's reference count while working with it. This is
not a risk for nailed relations of course, but it is a hazard for rels
with triggers. If this happens, RelationBuildTriggers will build a
TriggerDesc structure and then store its pointer into an already-freed
Relation struct. At the very least this represents a permanent memory
leak in CacheMemoryContext; but the scary thought is that the Relation
struct's memory might have already been recycled for another purpose,
in which case we have a memory clobber. So I'm of the opinion that we
need to back-patch all the way. Working on it now.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
