Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Alexander Korotkov <aekorotkov@gmail.com>
On Mon, Nov 6, 2023 at 3:42 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
>
> On Mon, 6 Nov 2023 at 17:07, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > On Wed, Jul 5, 2023 at 4:46 PM Aleksander Alekseev <aleksander@timescale.com> wrote:
> > > PFE the corrected patchset v58.
> >
> > I'd like to revive this thread.
> >
> > This patchset is extracted from a larger patchset implementing 64-bit xids. It converts page numbers in SLRUs into 64 bits. The most SLRUs save the same file naming scheme, thus their on-disk representation remains the same. However, the patch 0002 converts pg_notify to actually use a new naming scheme. Therefore pg_notify can benefit from simplification and getting rid of wraparound.
> >
> > -#define TransactionIdToCTsPage(xid) \
> > - ((xid) / (TransactionId) COMMIT_TS_XACTS_PER_PAGE)
> > +
> > +/*
> > + * Although we return an int64 the actual value can't currently exceeed 2**32.
> > + */
> > +static inline int64
> > +TransactionIdToCTsPage(TransactionId xid)
> > +{
> > + return xid / (int64) COMMIT_TS_XACTS_PER_PAGE;
> > +}
> >
> > Is there any reason we transform macro into a function? If not, I propose to leave this as a macro. BTW, there is a typo in a word "exceeed".
> 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.
> Also, I looked at v58-0001 and don't quite agree with mentioning the
> authors of the original 64-xid patch, from which the current patch is
> derived, as just "privious input" persons.
+1, for converting all "previous input" persons as additional authors.
That would be a pretty long list of authors though.
BTW, I'm a bit puzzled on who should be the first author now?
------
Regards,
Alexander Korotkov
Commits
-
Fix more holes with SLRU code in need of int64 for segment numbers
- b7935bc10b78 17.0 landed
- bd06cc338d82 18.0 landed
- e367a413b09f 17.0 landed
- c9e24573905b 18.0 landed
-
Use more consistently int64 for page numbers in SLRU-related code
- 165ea79a6077 17.0 landed
- 3937cadfd438 18.0 landed
-
Improve comments in slru.{c,h} about segment name format
- 3b279d89cb5c 17.0 landed
- ffb060392961 18.0 landed
-
Reorder actions in ProcArrayApplyRecoveryInfo()
- c64086b79dba 17.0 landed
-
Fix typo in 5a1dfde8334b
- ae2ccf66a261 17.0 landed
-
Fix warning due non-standard inline declaration in 4ed8f0913bfdb5f355
- b589f211e025 17.0 landed
-
Add SLRU tests for 64-bit page case
- a60b8a58f435 17.0 landed
-
Make use FullTransactionId in 2PC filenames
- 5a1dfde8334b 17.0 landed
-
Use larger segment file names for pg_notify
- 2cdf131c46e6 17.0 landed
-
Index SLRUs by 64-bit integers rather than by 32-bit integers
- 4ed8f0913bfd 17.0 landed
-
Keep track of transaction commit timestamps
- 73c986adde5d 9.5.0 cited
-
Handle 5-char filenames in SlruScanDirectory
- 638cf09e76d7 9.4.0 cited