I think we need int64 GUCs, due to these parameters（ autovacuum_freeze_table_age, autovacuum_freeze_max_age,When a table age is greater than any of these parameters an aggressive vacuum will be performed, When we implementing xid64, is it still necessary to be in the int range? btw, I have a suggestion to record a warning in the log when the table age exceeds the int maximum. These default values we can set a reasonable values ,for example autovacuum_freeze_max_age=4294967295 or 8589934592.
On Wed, Sep 25, 2024 at 6:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > FWIW, I agree with the upthread opinions that we shouldn't do this > (invent int64 GUCs). I don't think we need the added code bloat > and risk of breaking user code that isn't expecting this new GUC > type. We invented the notion of GUC units in part to ensure that > int32 GUCs could be adapted to handle potentially-large numbers. > And there's always the fallback position of using a float8 GUC > if you really feel you need a wider range.
Thank you for your feedback. Do you think we don't need int64 GUCs just now, when 64-bit transaction ids are far from committable shape? Or do you think we don't need int64 GUCs even if we have 64-bit transaction ids? If yes, what do you think we should use for *_age variables with 64-bit transaction ids?
