From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Антон Кузнецов <antosha86(at)mail(dot)ru> |
Cc: | pgsql-bugs(at)postgreSQL(dot)org |
Subject: | Re: Re[2]: BUG #5977: Crash on delete |
Date: | 2011-04-15 21:27:22 |
Message-ID: | 7270.1302902842@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
=?utf-8?Q?=D0=90=D0=BD=D1=82=D0=BE=D0=BD_=D0=9A=D1=83=D0=B7=D0=BD=D0=B5=D1=86=D0=BE=D0=B2?= <antosha86(at)mail(dot)ru> writes:
> TRAP: FailesAssertion("!(outerstartsel <= outerendsel)", File:
> "costsize.c", String: 1540)
On reflection it seems the only way you could get past the preceding
"Assert(outer_skip_rows <= outer_rows)" and then crash there would be
if outer_path_rows was NaN, which would result in both outerstartsel and
outerendsel becoming NaN, and then the comparison would fail to yield
true.
(A negative value of outer_path_rows would do it too, but that case has
been excluded at the top of the function.)
So the actual bug is presumably that some other piece of the planner is
returning NaN instead of a valid rowcount estimate. Unfortunately,
there are a whole lot of places to look, and not nearly enough
information here to narrow it down ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-04-15 21:27:59 | Re: BUG #5982: recursive type crashes postgres |
Previous Message | John R Pierce | 2011-04-15 21:19:55 | Re: BUG #5982: recursive type crashes postgres |