| 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: | Whole Thread | Raw Message | 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? |