Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe - Mailing list pgsql-committers

From Michael Paquier
Subject Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
Date
Msg-id 7AD52B27-1F6A-4F1B-9420-8C11ADAC6343@paquier.xyz
Whole thread Raw
In response to pgsql: Fix more holes with SLRU code in need of int64 for segment numbe  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
List pgsql-committers

> On Aug 8, 2024, at 5:05, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Wed, Aug 7, 2024 at 10:52 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>> It looks like the commit I'm talking about here is a subset of v55-0001
>> from that thread?
>
> Yes, looks like this.
>
>> So why is some of this being committed now into v17?
>> But as I wrote above, I think this approach is a bad idea.
>
> OK, I agree that might look annoying.  So, it's better to revert now.
> Michael, what do you think?

The argument is two-fold here. The point of this change is that we were forcibly doing a cast to int with int64 values
returned,so this commit limits the risks of missing paths in the future, while being consistent with all the SLRU code
markingsegment numbers with int64 for short *and* long segment file names. 

So at the end, I’d rather let the code as it is now, and keep a line of marking all the segment numbers with int64 and
beconsistent with what all the SLRU internals think what segment numbers should be. This is also the argument of Noah’s
upthreadas far as I understand (Noah, feel free to correct me if you think differently). 

(I’m without laptop access for quite a few days)
--
Michael



pgsql-committers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: pgsql: Introduce hash_search_with_hash_value() function
Next
From: Pavel Stehule
Date:
Subject: Re: pgsql: Introduce hash_search_with_hash_value() function