BRIN integer overflow
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t49225psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 11:14 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t49225_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t49225_1 && git checkout t49225_1Patchset v1 (message #1) is on t49225_1
Greetings, everyone!
While analyzing output of Svace static analyzer [1]https://svace.pages.ispras.ru/svace-website/en/ I've found a bug
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
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
The proposed patch is attached
[1]: https://svace.pages.ispras.ru/svace-website/en/
Oleg Tselebrovskiy, Postgres Pro
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