From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Postgresql 8.4.1 segfault, backtrace |
Date: | 2009-09-25 18:10:38 |
Message-ID: | 23979.1253902238@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2009-09-26 14:32:19 | Re: [JDBC] BUG #5058: [jdbc] Silent failure with executeUpdate() |
Previous Message | Tom Lane | 2009-09-25 18:01:34 | Re: Postgresql 8.4.1 segfault, backtrace |