> > > 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>
