Re: Add 64-bit XIDs into PostgreSQL 15
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Heikki Linnakangas <hlinnaka@iki.fi>,
Aleksander Alekseev <aleksander@timescale.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Maxim Orlov <orlovmg@gmail.com>,
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-07-25T13:31:05Z
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 →
-
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
On 25.07.24 13:09, Heikki Linnakangas wrote: >> However, if there is no more disaster threshold at 2^31, what is the >> guidance for setting these? Or more radically, why even run >> transaction-count-based vacuum at all? > > To allow the CLOG to be truncated. There's no disaster anymore, but > without freezing, the clog will grow indefinitely. Maybe a setting similar to max_wal_size could be better for that?