Re: BRIN integer overflow - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: BRIN integer overflow
Date
Msg-id 12FDC4B4-88E3-46F8-BDAA-05F0837F66BE@yesql.se
Whole thread Raw
In response to BRIN integer overflow  (Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru>)
List pgsql-hackers
> On 21 Feb 2024, at 06:40, Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru> wrote:

> Function bringetbitmap that is used in BRIN's IndexAmRoutine should return an
> int64 value, but the actual return value is int, since totalpages is int and
> totalpages * 10 is also int. This could lead to integer overflow

(totalpages * 10) overflowing an int seems like a quite theoretical risk which
would be hard to hit in practice.

> I suggest to change totalpages to be int64 to avoid potential overflow.
> Also in all other "amgetbitmap functions" (such as hashgetbitmap, gistgetbitmap,
> gingetbitmap, blgetbitmap) the return value is of correct int64 type

That being said, changing it like this seems reasonable since the API is
defined as int64, and it will keep static analyzers quiet.

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: POC: GROUP BY optimization
Next
From: Andy Fan
Date:
Subject: Re: Reduce useless changes before reassembly during logical replication