From: | Chris Travers <chris(dot)travers(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Shubham Khanna <khannashubham1197(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Chris Travers <chris(at)orioledata(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>, Fedor Sigaev <teodor(at)sigaev(dot)ru>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
Subject: | Re: Add 64-bit XIDs into PostgreSQL 15 |
Date: | 2024-07-25 12:18:47 |
Message-ID: | CAKt_ZfuUKmNHQrXAJCRaO+N11gG8jo1xiftzkuYpM8KMaab=bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 25, 2024 at 5:19 PM Peter Eisentraut <peter(at)eisentraut(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kirill Reshke | 2024-07-25 12:25:53 | Re: Remove duplicate table scan in logical apply worker and code refactoring |
Previous Message | Andrew Dunstan | 2024-07-25 12:12:38 | Re: fairywren timeout failures on the pg_amcheck/005_opclass_damage test |