Horton

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

Pavel Borisov <pashkin.elfe@gmail.com>

View thread View on postgr.es
From: Pavel Borisov <pashkin.elfe@gmail.com>
To: Aleksander Alekseev <aleksander@timescale.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>, Maxim Orlov <orlovmg@gmail.com>, Japin Li <japinli@hotmail.com>, Alexander Korotkov <aekorotkov@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Ilya Anfimov <ilan@tzirechnoy.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2022-03-22T08:31:58Z
Lists: pgsql-hackers 
>
> > 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>

Commits

  1. Fix more holes with SLRU code in need of int64 for segment numbers

  2. Use more consistently int64 for page numbers in SLRU-related code

  3. Improve comments in slru.{c,h} about segment name format

  4. Reorder actions in ProcArrayApplyRecoveryInfo()

  5. Fix typo in 5a1dfde8334b

  6. Fix warning due non-standard inline declaration in 4ed8f0913bfdb5f355

  7. Add SLRU tests for 64-bit page case

  8. Make use FullTransactionId in 2PC filenames

  9. Use larger segment file names for pg_notify

  10. Index SLRUs by 64-bit integers rather than by 32-bit integers

  11. Keep track of transaction commit timestamps

  12. Handle 5-char filenames in SlruScanDirectory