Re: BUG #18247: Integer overflow leads to negative width

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Junwang Zhao <zhjwpku@gmail.com>, rekgrpth@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-12-20T02:05:06Z
Lists: pgsql-bugs
On Tue, Dec 19, 2023 at 11:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Richard Guo <guofenglinux@gmail.com> writes:
> > On Tue, Dec 19, 2023 at 12:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Thanks for looking!  Do you have an opinion about the int64-vs-double
> >> question?
>
> > To be honest, I don't have a preference on which one is better.  I think
> > double is good enough for now as we don't need to worry about overflow
> > with it.
>
> After sleeping on it, I'm coming around to the idea that int64 will
> be better.  The argument that convinces me is that using int64
> provides a datatype-based clue that we are working with a width
> and not a row count, cost, or selectivity number.  I don't feel
> a need to go as far as invent a typedef alias like Cardinality;
> but plain "double" in the planner tends to be a rowcount estimate,
> which is not what we want people to think of.


Fair point.


> I'll make that change and push it.


Thanks for the change and pushing!


> BTW, I think it's sufficient to fix this in HEAD.  The troublesome
> example seems quite artificial to me, and we've not heard field
> reports suggesting that people have had real problems here.


Agreed.

Thanks
Richard

Commits

  1. Prevent integer overflow when forming tuple width estimates.

  2. compute_bitmap_pages' loop_count parameter should be double not int.