Horton

Re: Add 64-bit XIDs into PostgreSQL 15

Chris Travers <chris.travers@gmail.com>

View thread
From: Chris Travers <chris.travers@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Aleksander Alekseev <aleksander@timescale.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, 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>, 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-25T12:18:47Z
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 Thu, Jul 25, 2024 at 5:19 PM Peter Eisentraut <peter@eisentraut.org>
wrote:

> On 23.07.24 11:13, Aleksander Alekseev wrote:
> >> Here is the fix. It can be tested like this:
> >> [...]
> >
> > PFA the rebased patchset.
>
> 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
>

Also in the rebased patch set I cannot find the above, so I cannot evaluate
what it does.

In the past I have pushed for some mechanism to produce warnings like we
currently have approaching xid wraparound when a certain threshold is met.
Is this that mechanism?

>
> 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?
>
> 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.
>
> Your 0004 patch adds support for 64-bit GUCs but doesn't actually
> convert any existing GUCs to use that.  (Unlike the reloptions, which
> your patch coverts.)  And so there is no documentation about these
> questions.
>
>

-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more