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

From Peter Eisentraut
Subject Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
Date
Msg-id 92fe572d-638e-4162-aef6-1c42a2936f25@eisentraut.org
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 27.07.24 00:24, Michael Paquier wrote:
> Fix more holes with SLRU code in need of int64 for segment numbers
> 
> This is a continuation of 3937cadfd438, taking care of more areas I have
> managed to miss previously.
> 
> Reported-by: Noah Misch
> Reviewed-by: Noah Misch
> Discussion: https://postgr.es/m/20240724130059.1f.nmisch@google.com
> Backpatch-through: 17
> 
> Branch
> ------
> master
> 
> Details
> -------
> https://git.postgresql.org/pg/commitdiff/c9e24573905bef7fc3e4efb02bdb4d0cc8e43c51

I don't understand this patch.  The previous patches that this 
references changed various variables to int64 and made adjustments 
following from that.  But this patch takes variables and function 
results that are of type int and casts them to unsigned long long before 
printing.  I don't see what that accomplishes, and it's not clear based 
on just the explanation that this is a continuation of a previous patch 
that doesn't do that.  Is there a plan to change these things to int64 
as well at some point?





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