RE: error "can only drop stats once" brings down database
Floris Van Nee <florisvannee@optiver.com>
From: Floris Van Nee <florisvannee@Optiver.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
"pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2024-05-06T08:44:34Z
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
Commits
-
Add more debugging information when dropping twice pgstats entry
- 2de059de2c2d 15.8 landed
- 83f415e2d92e 16.4 landed
- d92573adcb02 17.0 landed