From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql <pgsql(at)lavabit(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Please help me debug regular segfaults on 8.3.10 |
Date: | 2010-05-06 14:13:44 |
Message-ID: | 15942.1273155224@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
pgsql <pgsql(at)lavabit(dot)com> writes:
> Tom Lane wrote:
>> Um, that's not too helpful, we want to see the string it's pointing at.
> Sorry about that. All statements are calling one of two pl/pgsql
> functions. While that information already helps me a lot, it'll take me
> a while to step through the code. Those functions are outer wrappers
> calling many other procedures.
Well, the stack trace you showed previously indicates that the crash is
happening in the outermost plpgsql function (ie, one called directly
from a client SQL command). However it's certainly true that the crash
might be a consequence of something that had been done a bit earlier in
another function called by this one.
Keep in mind that the crash very likely doesn't happen when you simply
step through the function in isolation. If it is the same as or
related to the previously-fixed bug, it would only happen if a cache
flush event happened at just the wrong time (as a consequence of
sufficiently many concurrent catalog updates issued by other processes).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Vitek | 2010-05-06 14:44:34 | pre-existing shared memory block is still in use after crashes |
Previous Message | Tatsuo Ishii | 2010-05-06 13:06:01 | Re: lobj_lock_table structure |