Horton

Re: Add 64-bit XIDs into PostgreSQL 15

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
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:20:33Z
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

Hi,

On 2022-11-21 15:16:46 -0500, Tom Lane wrote:
> 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.

Sure looks that way to me. I think it might mostly work if you manage to
find nextXid, nextMulti, nextMultiOffset values that each point to the
start of a segment that'd then be created whenever those values are
used.

Greetings,

Andres Freund