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