Division by zero in planner.c:grouping_planner()
Hello,
with the change below, make installcheck fails -- at the updatable_views
step, I believe. Apparently it's the "SELECT * FROM v1 WHERE a=3;" that
triggers this.
diff --git a/src/backend/optimizer/plan/planner.c
b/src/backend/optimizer/plan/planner.c
index 6ee411e..cbdee7c 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -1661,6 +1661,7 @@ grouping_planner(PlannerInfo *root, double
tuple_fraction)
* Plain non-grouped, non-aggregated query: an
absolute tuple
* fraction can be divided by the number of tuples.
*/
+ Assert(path_rows != 0);
if (tuple_fraction >= 1.0)
tuple_fraction /= path_rows;
}--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jul 29, 2015 at 11:26 AM, Piotr Stefaniak
<postgres@piotr-stefaniak.me> wrote:
+ Assert(path_rows != 0);
if (tuple_fraction >= 1.0)
tuple_fraction /= path_rows;
}
This does not sounds right: path_rows only used when tuple_fractions
= 1.0. So the new Assert is an overkill.
Regards,
Qingqing
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Qingqing Zhou <zhouqq.postgres@gmail.com> writes:
On Wed, Jul 29, 2015 at 11:26 AM, Piotr Stefaniak
<postgres@piotr-stefaniak.me> wrote:+ Assert(path_rows != 0);
if (tuple_fraction >= 1.0)
tuple_fraction /= path_rows;
}
This does not sounds right: path_rows only used when tuple_fractions
= 1.0. So the new Assert is an overkill.
Well, the point is that we'll get a zero-divide if path_rows is zero.
It looks to me like the planner has managed to prove that the result
is empty (because a=3 contradicts a>5), so it's marked the final_rel
as dummy, which includes setting its rows estimate to zero. In most
situations relation rows estimates aren't allowed to be zero, which
is how come this code isn't expecting the case ... but it needs to
cope with it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers