Horton

Re: Add 64-bit XIDs into PostgreSQL 15

Heikki Linnakangas <hlinnaka@iki.fi>

View thread
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Peter Eisentraut <peter@eisentraut.org>, 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-25T11:09:10Z
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

On 25/07/2024 13:19, Peter Eisentraut wrote:
> I'm wondering about the 64-bit GUCs.
> 
> At first, it makes sense that if there are settings that are counted in 
> terms of transactions, and transaction numbers are 64-bit integers, then 
> those settings should accept 64-bit integers.
> 
> But what is the purpose and effect of setting those parameters to such 
> huge numbers?  For example, what is the usability of being able to set
> 
> vacuum_failsafe_age = 500000000000
> 
> I think in the world of 32-bit transaction IDs, you can intuitively 
> interpret most of these "transaction age" settings as "percent toward 
> disaster".  For example,
> 
> vacuum_freeze_table_age = 150000000
> 
> is 7% toward disaster, and
> 
> vacuum_failsafe_age = 1600000000
> 
> is 75% toward disaster.
> 
> 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.

> Conversely, if there is still some threshold (not disaster, but 
> efficiency or something else), would it still be useful to keep these 
> settings well below 2^31?  In which case, we might not need 64-bit GUCs.

Yeah, I don't think it's critical. It makes sense to switch to 64 bit 
GUCs, so that you can make those settings higher, but it's not critical 
or strictly required for the rest of the work.

Another approach is to make the GUCs to mean "thousands of XIDs", 
similar to how many of our memory settings are in kB rather than bytes. 
that might be a super confusing change for existing settings though.

-- 
Heikki Linnakangas
Neon (https://neon.tech)