On 25/07/2024 13:19, Peter Eisentraut wrote:
> 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?
To allow the CLOG to be truncated. There's no disaster anymore, but
without freezing, the clog will grow indefinitely.
> 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.
Yeah, I don't think it's critical. It makes sense to switch to 64 bit
GUCs, so that you can make those settings higher, but it's not critical
or strictly required for the rest of the work.
Another approach is to make the GUCs to mean "thousands of XIDs",
similar to how many of our memory settings are in kB rather than bytes.
that might be a super confusing change for existing settings though.
--
Heikki Linnakangas
Neon (https://neon.tech)
