Re: Add 64-bit XIDs into PostgreSQL 15

Aleksander Alekseev <aleksander@timescale.com>

From: Aleksander Alekseev <aleksander@timescale.com>
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Cc: Pavel Borisov <pashkin.elfe@gmail.com>, Stephen Frost <sfrost@snowman.net>, Alexander Korotkov <aekorotkov@gmail.com>, Andres Freund <andres@anarazel.de>, Ilya Anfimov <ilan@tzirechnoy.com>, Maxim Orlov <orlovmg@gmail.com>
Date: 2022-03-08T16:27:16Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add SLRU tests for 64-bit page case

  2. Make use FullTransactionId in 2PC filenames

  3. Use larger segment file names for pg_notify

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

Attachments

Hi hackers,

> I extracted the introduction of XID_FMT macro to a separate patch. Also,
> I noticed that sometimes PRIu64 was used to format XIDs instead. I changed it
> to XID_FMT for consistency. v12-0003 can be safely delivered in PG15.

[...]

> > > I encourage trying to break down the patch into smaller incrementally useful
> > > pieces. E.g. making all the SLRUs 64bit would be a substantial and
> > > independently committable piece.
> >
> > I'm going to address this in follow-up emails.
>
> cfbot is not happy because several files are missing in v12. Here is a
> corrected and rebased version. I also removed the "#undef PRIu64"
> change from include/c.h since previously I replaced PRIu64 usage with
> XID_FMT.

Here is a new version of the patchset. SLRU refactoring was moved to a
separate patch. Both v14-0003 (XID_FMT macro) and v14-0004 (SLRU
refactoring) can be delivered in PG15.

One thing I couldn't understand so far is why SLRU_PAGES_PER_SEGMENT
should necessarily be increased in order to make 64-bit XIDs work. I
kept the current value (32) in v14-0004 but changed it to 2048 in
./v14-0005 (where we start using 64 bit XIDs) as it was in the
original patch. Is this change really required?

--
Best regards,
Aleksander Alekseev