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>
Thread-Topic: [External] Re: error "can only drop stats once" brings down
 database [External]
Thread-Index: AQHaZC2BJX3cZ68Gf0SnR3ukCGL5orGGQZEwgALhs4CAAGv+AIAAxH3g
Date: Mon, 6 May 2024 08:44:34 +0000
Message-ID: <40d6f8b377e446dc860d8b2c02fc9d99@Optiver.com>
References: <b14ae28029f64757bb64613be2549a74@Optiver.com>
 <215498.1708454947@sss.pgh.pa.us>
 <8e5cb534706a4f43bd74405c8fd91437@Optiver.com>
 <20240505160915.6boysum4f34siqct@awork3.anarazel.de>
 <20240505223546.6yvjzgqifuoiii3e@awork3.anarazel.de>
In-Reply-To: <20240505223546.6yvjzgqifuoiii3e@awork3.anarazel.de>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: error "can only drop stats once" brings down database
Archived-At: 
 <https://www.postgresql.org/message-id/40d6f8b377e446dc860d8b2c02fc9d99%40Optiver.com>
Precedence: bulk

>=20
> Could you confirm that you have a) a lot of oid assignments b) your start=
up
> process was running for a long time by the time of the crash?
>=20

Thanks Andres. Both higher than average I guess, although it depends on wha=
t 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 (T=
imescale) partitions. However, even with this number of items in pg_class I=
 would't expect wraparound to happen frequently? These are not dropped/recr=
eated. 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 tempo=
rary tables being created), it also doesn't nearly happen at a frequency th=
at will get us to a wraparound quickly.

Oids aren't just consumed by pg_class though. And I do see system oid growi=
ng quickly (when doing CREATE TABLE twice with a minute in between, then ch=
ecking the oid difference of the table). I don't know how to investigate th=
e cause of this. What would be the best way to check what could be consumin=
g these oids so quickly?

-Floris