Horton

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

Aleksander Alekseev <aleksander@timescale.com>

View thread View on postgr.es
From: Aleksander Alekseev <aleksander@timescale.com>
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Cc: Alexander Korotkov <aekorotkov@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Maxim Orlov <orlovmg@gmail.com>, Japin Li <japinli@hotmail.com>, Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2023-11-06T14:28:23Z
Lists: pgsql-hackers 
Hi,

> > > If I remember right, the compiler will make equivalent code from
> > > inline functions and macros, and functions has an additional benefit:
> > > the compiler will report type mismatch if any. That was the only
> > > reason.
> >
> > Then it's OK to leave it as an inline function.

+1

> > BTW, I'm a bit puzzled on who should be the first author now?
> Thanks! It's long, I agree, but the activity around this was huge and
> involved many people, the patch itself already has more than
> half-hundred iterations to date. I think at least people mentioned in
> the commit message of v58 are fair to have author status.
>
> As for the first, I'm not sure, it's hard for me to evaluate what is
> more important, the initial prototype, or the final improvement
> iterations. I don't think the existing order in a commit message has
> some meaning. Maybe it's worth throwing a dice.

Personally I was not aware that the order of the authors in a commit
message carries any information. To my knowledge it doesn't not. I
believe this patchset is a team effort, so I suggest keeping the
commit message as is or shuffling the authors randomly. I believe we
should do our best to reflect the input of people who previously
contributed to the effort, if anyone are aware of them, and add them
to the commit message if they are not there yet. Pretty sure Git will
forgive us if the list ends up being long. Hopefully so will people
who we mistakenly forget.

-- 
Best regards,
Aleksander Alekseev

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