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