Re: BUG #18247: Integer overflow leads to negative width
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Junwang Zhao <zhjwpku@gmail.com>, rekgrpth@gmail.com,
pgsql-bugs@lists.postgresql.org
Date: 2023-12-19T15:22:20Z
Lists: pgsql-bugs
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. I'll make that change and push it. 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. regards, tom lane
Commits
-
Prevent integer overflow when forming tuple width estimates.
- 7e1ce2b3de16 17.0 landed
-
compute_bitmap_pages' loop_count parameter should be double not int.
- 8b965c549dc8 17.0 landed