Re: Division by zero in planner.c:grouping_planner()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com>
Cc: Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Division by zero in planner.c:grouping_planner()
Date: 2015-07-30 04:19:57
Message-ID: 5114.1438229997@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com> writes:
> On Wed, Jul 29, 2015 at 11:26 AM, Piotr Stefaniak
> <postgres(at)piotr-stefaniak(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2015-07-30 04:41:29 Re: dblink: add polymorphic functions.
Previous Message Tom Lane 2015-07-30 03:17:42 Re: The real reason why TAP testing isn't ready for prime time