=?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?=
<antosh...@mail.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
