Re: Avoid a possible overflow (src/backend/utils/sort/logtape.c)
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Geoghegan <pg@bowt.ie>, Ranier Vilela <ranier.vf@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2023-08-25T01:43:47Z
Lists: pgsql-hackers
On Fri, 25 Aug 2023 at 13:19, Michael Paquier <michael@paquier.xyz> wrote: > Still that looks entirely different to me. Here we have a problem > where the number of free blocks stored may cause an overflow in the > internal routine retrieving a free block, but your other thread > is about long being not enough on Windows. I surely agree that > there's an argument for improving this interface and remove its use of > long in the long-term but that would not be backpatched. I also don't > see why we cannot do the change proposed here until then, and it's > backpatchable. I agree with this. I think Ranier's patch is good and we should apply it and backpatch it. We shouldn't delay fixing this simple bug because we have some future ambitions to swap the use of longs to int64. David
Commits
-
Avoid possible overflow with ltsGetFreeBlock() in logtape.c
- 420c8dc7ec67 13.13 landed
- d2bd4ba30585 14.10 landed
- 5180160c1774 15.5 landed
- 1d2939b6dc63 16.0 landed
- 52c6c0f19693 17.0 landed