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
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.
