Horton

Re: Add 64-bit XIDs into PostgreSQL 15

Aleksander Alekseev <aleksander@timescale.com>

View thread
From: Aleksander Alekseev <aleksander@timescale.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Maxim Orlov <orlovmg@gmail.com>, Michael Paquier <michael@paquier.xyz>, Heikki Linnakangas <hlinnaka@iki.fi>, Peter Eisentraut <peter@eisentraut.org>, Shubham Khanna <khannashubham1197@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Pavel Borisov <pashkin.elfe@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Chris Travers <chris@orioledata.com>, Bruce Momjian <bruce@momjian.us>, Chris Travers <chris.travers@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Fedor Sigaev <teodor@sigaev.ru>, Alexander Korotkov <aekorotkov@gmail.com>, Konstantin Knizhnik <knizhnik@garret.ru>, Nikita Glukhov <n.gluhov@postgrespro.ru>, Yura Sokolov <y.sokolov@postgrespro.ru>
Date: 2024-09-12T09:52:18Z
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

Michael, Maxim,

> Apparently, the original thread will inevitably disintegrate into many separate ones.
> For me, looks like some kind of road map. One for 64-bit GUCs, another one to remove
> short file names from SLRUs and, to make things more complicated, [1] for cf entry [0],
> to get rid of MultiXactOffset wraparound by switching to 64 bits.
>
> [0] https://commitfest.postgresql.org/49/5205/
> [1] https://www.postgresql.org/message-id/flat/CACG%3DezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw%40mail.gmail.com

Agree.

To me it seems like we didn't reach a consensus regarding switching to
64-bit XIDs. Given that and the fact that the patchset is rather
difficult to rebase (and review) I suggest focusing on something we
reached a consensus for. I'm going to close a CF entry for this
particular thread as RwF unless anyone objects. We can always return
to this later, preferably knowing that there is a particular committer
who has time and energy for merging this.

-- 
Best regards,
Aleksander Alekseev