| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| 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:21:27 |
| Message-ID: | 156738.1788751287@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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".
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-09-07 03:34:21 | Re: pg_createsubscriber: allow duplicate subscription names |
| Previous Message | Michael Paquier | 2026-09-07 03:13:44 | Re: Direct TOAST v2, faster, smaller and no migration needed |