| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Subject: | Re: SUM(int2)/SUM(int4) do not detect overflow of the int8 accumulator |
| Date: | 2026-09-07 03:01:50 |
| Message-ID: | CAApHDvoc36xXLHhyMfFwh0ODWsvQA=aaVZkF3Gnu8HCWcuSjTw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2026-09-07 03:03:45 | Re: Assert failure in try_nestloop_path() |
| Previous Message | Greg Sabino Mullane | 2026-09-07 02:15:52 | Re: POC: Carefully exposing information without authentication |