On Thu, Aug 27, 2026 at 10:45 AM David Rowley <[email protected]> wrote: > > On Thu, 27 Aug 2026 at 14:27, Ewan Young <[email protected]> wrote: > > Rather than pile that cleanup onto this bug-fix thread, I'll send it as a > > separate follow-up so this fix can be considered on its own. Will post > > that shortly and CC you three. > > Yes, another thread. Please also include a description of your method > for verifying the code matches for non-HAVE__BUILTIN_OP_OVERFLOW > builds. > > Also, pg_neg_s32_overflow() was introduced in 2024 by 0a27c3d0f733, > which is v18+. Depending on Daniel's patience for backpatching two > different versions, it might be worth just using the == PG_INT32_MIN > method to fix the bug, then allowing the follow-up patch to switch > that in v20 only. That would mean v18 and v19 don't get the most > optimal fix, but it's hard to imagine that's going to be performance > critical.
Thanks, that plan makes sense to me -- let's keep the bug fix uniform
across all branches and do the pg_neg_s32_overflow() switch separately.
pg_neg_s32_overflow() only exists from v18 (0a27c3d0f733), while the bug
goes all the way back, so using it in the fix would mean carrying two
versions for the back-branches. Not worth it for a one-liner.
Attached v4 goes back to the explicit PG_INT32_MIN test:
if (unlikely(n == PG_INT32_MIN))
n = PG_INT32_MAX;
else
n = -n;
which applies cleanly to every supported branch (I checked REL_14 through
REL_19 and master). The fix and the regression case are otherwise
unchanged.
I'll take the pg_neg_s32_overflow() cleanup to its own thread, master
only, covering the other open-coded negation checks Ilmari pointed at
(int2/4/8 um/abs/div, lcm, cash, numericvar_to_int64); once this fix
lands I'll fold text_right() into that too. So the back-branches keep the
plain form and only master gets the helper.
>
> David
--
Regards,
Ewan Young
v4-0001-Fix-right-with-the-most-negative-integer.patch
Description: Binary data
