From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: FailedAssertion() in 8.2beta1 |
Date: | 2006-10-07 19:27:46 |
Message-ID: | 87k63c3ozx.fsf@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> "Sergey E. Koposov" <math(at)sai(dot)msu(dot)ru> writes:
>> I've found a bug with 8.2beta1:
>
> Can you put together a self-contained test case for this? The planner
> is evidently generating an incorrect plan from that messy view, but
> trying to reverse-engineer the complete scenario from what you've told
> us looks painful. (No, I don't think the log setting is related.)
Would a core dump file (and his binary) be useful?
Earlier I was going to suggest he execute these commands from gdb:
f 5
p *rtentry
p *estate
But I fear even that won't be enough to actually track down where the state
got corrupted.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-07 19:47:45 | Re: FailedAssertion() in 8.2beta1 |
Previous Message | Josh Berkus | 2006-10-07 18:51:08 | Re: Select for update with outer join broken? |