Re: FailedAssertion() in 8.2beta1

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

In response to

Browse pgsql-hackers by date

  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?