Re: BRIN integer overflow

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Oleg Tselebrovskiy <o(dot)tselebrovskiy(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BRIN integer overflow
Date: 2024-02-21 10:31:36
Message-ID: 12FDC4B4-88E3-46F8-BDAA-05F0837F66BE@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 21 Feb 2024, at 06:40, Oleg Tselebrovskiy <o(dot)tselebrovskiy(at)postgrespro(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2024-02-21 10:47:40 Re: Reduce useless changes before reassembly during logical replication
Previous Message Alexander Korotkov 2024-02-21 10:19:53 Re: POC: GROUP BY optimization