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

On Mon, 7 Sept 2026 at 15:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > On Sun, 6 Sept 2026 at 05:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> * In the avg_accum functions, we can argue about how likely it
> >> is that we'd reach overflow of the "sum" fields, but it is completely
> >> insane to expend cycles and code complexity to check for overflow of
> >> the "count" fields. If you can reach 2^63 by repeated addition of 1
> >> within the lifetime of a PG database, then we have got far worse
> >> problems, eg with WAL LSN overflow.
>
> > I thought the same thing and wondered where that came from. On looking
> > at int8inc(), I saw there's a similar check, which seems equally
> > unlikely to hit, so I didn't mention it.
>
> int8inc doesn't really have a basis to suppose that it's starting
> from count zero, does it? It's a SQL-accessible function defined
> as "add one".

That's a good point. I now agree that checking for overflow on the
count for the avg_accum functions is a waste of effort.

David