On Thu, Jul 25, 2024 at 5:19 PM Peter Eisentraut <pe...@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. http://www.efficito.com/learn_more
