On Mon, 7 Sept 2026 at 15:21, Tom Lane <[email protected]> wrote: > > David Rowley <[email protected]> writes: > > On Sun, 6 Sept 2026 at 05:01, Tom Lane <[email protected]> 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
