Re: SUM(int2)/SUM(int4) do not detect overflow of the int8 accumulator

On Wed, 21 Oct 2026 at 12:14, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> I've split Andrei's v3 into two patches. 0001 is the new macro to
> return the input, and 0002 is Andrei's overflow checks. I ended up
> renaming the PG_RETURN_INPUT() to PG_RETURN_ARG() as I thought it
> better combined the existing names of PG_GETARG_* and PG_RETURN_*.

I've pushed both of these patches now. Before I pushed 0002, I was
playing around with queries to see how quickly I could hit an
overflow. The best I came up with was 4.4 seconds on a Zen2 64-core
machine.

create table t (a int, v int);
insert into t select s,2147483647 from generate_series(1,65536)s;
vacuum freeze analyze t;
alter table t set (parallel_workers=64);
alter system set max_parallel_workers=100;
alter system set max_worker_processes=100;
select pg_reload_conf();
-- restart
set max_parallel_workers_per_gather = 64;
set min_parallel_table_scan_size = 0;

select sum(t.v),count(*) from t, generate_Series(1,65537);
ERROR: bigint out of range
Time: 4404.796 ms (00:04.405)

That did overflow prior to the patch as the combine function (int8pl)
does already have overflow checking. So whether you got the overflow
or not could have depended on chance, depending on how work was
distributed between parallel workers. I didn't think that was great,
so I was more in favour of adding these checks after seeing that.

David