Re: Add 64-bit XIDs into PostgreSQL 15

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Maxim Orlov <orlovmg@gmail.com>, Thom Brown <thom@linux.com>, Zhang Mingli <zmlpostgres@gmail.com>, Michael Paquier <michael@paquier.xyz>, Justin Pryzby <pryzby@telsasoft.com>, Dilip Kumar <dilipbalaut@gmail.com>, Pavel Borisov <pashkin.elfe@gmail.com>, Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers@lists.postgresql.org, Stephen Frost <sfrost@snowman.net>, Alexander Korotkov <aekorotkov@gmail.com>, Ilya Anfimov <ilan@tzirechnoy.com>
Date: 2022-11-21T20:16:46Z
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

Andres Freund <andres@anarazel.de> writes:
> On 2022-11-21 14:21:35 -0500, Tom Lane wrote:
>> pg_resetwal does seem like a better, more useful home for this; it'd
>> allow you to adjust these numbers after initial creation which might be
>> useful.  I'm not sure how flexible it is right now in terms of where
>> you can set the new values, but that can always be improved.

> IIRC the respective pg_resetwal parameters are really hard to use for
> something like this, because they don't actually create the respective
> SLRU segments. We of course could fix that.

Is that still true?  We should fix it, for sure.

			regards, tom lane