| From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
|---|---|
| To: | wenhui qiu <qiuwenhuifx(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Li Japin <japinli(at)hotmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Subject: | Re: [PATCH] Support Int64 GUCs |
| Date: | 2024-09-26 15:55:07 |
| Message-ID: | CAPpHfdusZDd_6ACM5iyk_RNTJVumZsZv1hmrmS+QuCVva1fESA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 26, 2024 at 12:30 PM wenhui qiu <qiuwenhuifx(at)gmail(dot)com> wrote:
> 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.
In principle, even with 64-bit transaction ids we could specify *_age
GUCs as int32 with bigger units or as float8. That feels a bit
awkward for me. This is why I queried more about Tom's opinion in
more details: did he propose to wait with int64 GUCs before we have
64-bit transaction ids, or give up about them completely?
Links.
1. https://www.postgresql.org/message-id/3649727.1727276882%40sss.pgh.pa.us
------
Regards,
Alexander Korotkov
Supabase
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-09-26 16:39:10 | Re: [PATCH] Support Int64 GUCs |
| Previous Message | Tom Lane | 2024-09-26 15:51:47 | Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges |