Skip site navigation (1) Skip section navigation (2)

Re: Postgresql 8.4.1 segfault, backtrace

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: (view raw, whole thread or download thread mbox)
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

In response to

pgsql-bugs by date

Next:From: Kris JurkaDate: 2009-09-26 14:32:19
Subject: Re: [JDBC] BUG #5058: [jdbc] Silent failure with executeUpdate()
Previous:From: Tom LaneDate: 2009-09-25 18:01:34
Subject: Re: Postgresql 8.4.1 segfault, backtrace

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group