Re: Avoid a possible overflow (src/backend/utils/sort/logtape.c)

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Michael Paquier <michael@paquier.xyz>
Cc: Ranier Vilela <ranier.vf@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2023-08-25T01:55:00Z
Lists: pgsql-hackers
On Thu, Aug 24, 2023 at 6:18 PM 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 must have seen logtape.c, windows, and long together on this thread,
and incorrectly surmised that it was exactly the same issue as before.
I now see that the only sense in which Windows is relevant is that
Windows happens to not have the same inconsistency. Windows is
consistently wrong.

So, yeah, I guess it's a different issue. Practically speaking it
should be treated as a separate issue, in any case. Since, as you
pointed out, there is no reason to not just fix this while
backpatching.

-- 
Peter Geoghegan



Commits

  1. Avoid possible overflow with ltsGetFreeBlock() in logtape.c