Re: Postgresql 8.4.1 segfault, backtrace

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