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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: fairywren timeout failures on the pg_amcheck/005_opclass_damage test
Следующее
От: Kirill Reshke
Дата:
Сообщение: Re: Remove duplicate table scan in logical apply worker and code refactoring