Hi Alexander
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.
Thanks
Alexander Korotkov <aekorot...@gmail.com> 于2024年9月26日周四 02:05写道：
> Hi, Tom!
>
> On Wed, Sep 25, 2024 at 6:08 PM Tom Lane <t...@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?
>
> ------
> Regards,
> Alexander Korotkov
> Supabase
>
>
>
