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 e1260254-aba7-48e4-89db-98a001b97d71@eisentraut.org
Whole thread Raw
In response to Re: 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 08.08.24 01:15, Michael Paquier wrote:
> 
>> 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
valuesreturned, so this commit limits the risks of missing paths in the future, while being consistent with all the
SLRUcode marking segment numbers with int64 for short *and* long segment file names.
 

No, this is not what *this* patch does.  (I suppose some of the related 
patches might be doing that.)  This patch just casts a few things that 
are int to unsigned long long int before printing them.




pgsql-committers by date:

Previous
From: Peter Eisentraut
Date:
Subject: pgsql: Remove obsolete RECHECK keyword completely
Next
From: Tom Lane
Date:
Subject: pgsql: Fix "failed to find plan for subquery/CTE" errors in EXPLAIN.