On Wed, Aug 7, 2024 at 12:07 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> 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?
There is a plan indeed. The patchset [1] should include conversion
multixacts to 64-bit (It surely included that in earlier versions, I
didn't look the last versions though). I doubt this will be ready for
v18. So this commit might be quite preliminary. But I would prefer
to leave it there as soon as it has already landed. Opinions?
Links.
1. https://www.postgresql.org/message-id/CAJ7c6TND0bCnwU1SmxTsFewK4XJGBep343vf%2BT%2BGQ-a5S5hC0w%40mail.gmail.com
------
Regards,
Alexander Korotkov
Supabase
