Re: [PATCH] Support Int64 GUCs
| От | wenhui qiu |
|---|---|
| Тема | Re: [PATCH] Support Int64 GUCs |
| Дата | |
| Msg-id | CAGjGUALj0Ty0pv_7dseJRkSbHWZJM9-mOUdfs4Y=nUa-HGcTOw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Support Int64 GUCs (Alexander Korotkov <aekorotkov@gmail.com>) |
| Ответы |
Re: [PATCH] Support Int64 GUCs
|
| Список | pgsql-hackers |
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 <aekorotkov@gmail.com> 于2024年9月26日周四 02:05写道：
Hi, Tom!
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?
------
Regards,
Alexander Korotkov
Supabase
В списке pgsql-hackers по дате отправления: