| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | 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-02 06:01:56 |
| Message-ID: | 3868345a-9a2c-48b9-9e40-a8a91cd06699@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 02/09/2026 07:42, Chao Li wrote:
>
>
>> On Sep 1, 2026, at 16:22, Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>>
>> On 01/09/2026 09:35, Chao Li wrote:
>>> If newval is negative, the minus operation may also overflow.
>> I don't think that's the case. An inverted function removes values that were
>> already included in the aggregate, which usually brings the total closer to zero
>> instead of pushing it toward the boundary. From what I see, this means there's
>> no risk of integer overflow.
> I agree that this may not happen during normal aggregate execution, but int2_avg_accum_inv() is also directly callable as a SQL function.
In my mind, we should pay for CPU cycles only in practical cases. So, if this
case deserves an overflow check, it should be an assertion that consumes no
resources in production.
--
regards, Andrei Lepikhov,
pgEdge
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ewan Young | 2026-09-02 06:07:57 | Re: RANGE partition pruning can still exclude the default partition |
| Previous Message | Chao Li | 2026-09-02 05:42:49 | Re: SUM(int2)/SUM(int4) do not detect overflow of the int8 accumulator |