Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

>
> > I think there needs to be a bit more soul searching here on how to
> > handle that in the future and how to transition it. I don't think
> > targeting this patch for PG15 is useful at this point.
>
> The patches can be reordered so that we are still able to deliver SLRU
> refactoring in PG15.
>
Sure.

> > As a more general point, I don't like plastering these bulky casts all
> > over the place. Casts hide problems.
>
> Regarding the casts, I don't like them either. I agree that it could
> be a good idea to invest a little more time into figuring out if this
> transit can be handled in a better way and deliver this change in the
> next CF. However, if no one will be able to suggest a better
> alternative, I think we should continue making progress here. The
> 32-bit XIDs are a major inconvenience for many users.
>

I'd like to add that the initial way of shifting to 64bit was based on
XID_FMT in a print formatting template which could be changed from 32 to 64
bit when shifting to 64-bit xids later. But this template is not
localizable so hackers recommended using %lld/%llu with (long
long)/(unsigned long long cast) which is a current best practice elsewhere
in the code (e.g. recent 1f8bc448680bf93a9). So I suppose we already have a
good enough way to stick to.

This approach in 0001 inherently processes both 32/64 bit xids and should
not change with later committing 64bit xids later (
https://postgr.es/m/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
)

The thing that needs to change then is suppressing output of Epoch. It
should be done when 64-xids are committed and it is done by 0006 in the
mentioned thread. Until that I've left Epoch in the output.

Big thanks for your considerations!

--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>