Re: Add 64-bit XIDs into PostgreSQL 15
От | Chris Travers |
---|---|
Тема | Re: Add 64-bit XIDs into PostgreSQL 15 |
Дата | |
Msg-id | CAKt_ZfuUKmNHQrXAJCRaO+N11gG8jo1xiftzkuYpM8KMaab=bg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add 64-bit XIDs into PostgreSQL 15 (Peter Eisentraut <peter@eisentraut.org>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: