Re: error "can only drop stats once" brings down database
От | Andres Freund |
---|---|
Тема | Re: error "can only drop stats once" brings down database |
Дата | |
Msg-id | 20240505223546.6yvjzgqifuoiii3e@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: error "can only drop stats once" brings down database (Andres Freund <andres@anarazel.de>) |
Ответы |
RE: error "can only drop stats once" brings down database
RE: error "can only drop stats once" brings down database |
Список | pgsql-bugs |
Hi, On 2024-05-05 09:09:15 -0700, Andres Freund wrote: > Do you have any more details about the workload leading to this issue? Is the > standby used for queries? Given the "high value" your oids/relfilenodes have, > I assume there are a lot of created/dropped/truncated relations? I suspect that the "high value" oids are related to the issue. I bet you're running into OID wraparound for objects at a much higher frequency than most users. I suspect the reason this causes problems is the problem I just found and described here: https://www.postgresql.org/message-id/20240505183741.5tefii3razzefvtc%40awork3.anarazel.de 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? The fact that we're not triggering "stats object garbage collection" for most drops also explains why you're much more likely to see this on a standby than on a primary. An a primary it's going to be rare to have a single backend live long enough to observe an oid wraparound leading to one backend accessing stats for the same object type with the same oid after that object previously having been dropped. But most stats accesses on a standby are going to be by the same process, the startup process. You'd still need some other accesses to prevent the object from being dropped "immediately", but that could be due to shorter lived processes. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: