From: | Floris Van Nee <florisvannee(at)Optiver(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | RE: error "can only drop stats once" brings down database |
Date: | 2024-05-06 08:44:34 |
Message-ID: | 40d6f8b377e446dc860d8b2c02fc9d99@Optiver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>
> Could you confirm that you have a) a lot of oid assignments b) your startup
> process was running for a long time by the time of the crash?
>
Thanks Andres. Both higher than average I guess, although it depends on what is considered 'a lot' and 'a long time'. The startup process was running for a few months. There are ~500k entries in pg_class, of which most are (Timescale) partitions. However, even with this number of items in pg_class I would't expect wraparound to happen frequently? These are not dropped/recreated. I've monitored "select count(*) from pg_class" for a while to see if it changes often, and while there are changes during the day (likely temporary tables being created), it also doesn't nearly happen at a frequency that will get us to a wraparound quickly.
Oids aren't just consumed by pg_class though. And I do see system oid growing quickly (when doing CREATE TABLE twice with a minute in between, then checking the oid difference of the table). I don't know how to investigate the cause of this. What would be the best way to check what could be consuming these oids so quickly?
-Floris
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-05-06 14:41:11 | Re: BUG #18456: Trigger data in plpython3u trigger-function changes in AFTER UPDATE OR INSERT trigger |
Previous Message | Jacques Combrink | 2024-05-06 08:36:49 | Re: BUG #18456: Trigger data in plpython3u trigger-function changes in AFTER UPDATE OR INSERT trigger |