On Tue, Sep 16, 2025 at 02:45:03PM +0300, Kouber Saparev wrote: > На пт, 12.09.2025 г. в 3:37 Michael Paquier <[email protected]> написа: >> With which process has this cascading standby been created? >> Does the workload of the primary involve a high consumption of OIDs >> for relations, say many temporary tables? > > Yes, we have around 150 entries added and deleted per second in pg_class, > and around 800 in pg_attribute. So something is actively creating and > dropping tables all the time.
The number of relations would most likely matter, I doubt that pg_attribute contributes a lot in the frictions. One of the test scenarios I am running is exactly that: a bunch of CREATE/DROP tables running concurrently with backends in a cascading standby accessing them, while tweaking the OID generated in the control file to force wraparounds. I am failing to re-create your problem, for now at least. > > Another thing that may help is the WAL record history. Are you for > > example seeing attempts to drop twice the same pgstats entry in WAL > > records? Perhaps the origin of the problem is in this area. A > > refcount of 2 is relevant, of course. > > > > How could we dig into this, i.e. inspecting such attempts in the WAL > records? Yeah, with pg_walinspect or pg_waldump, but I doubt that you retain enough WAL history to be able to ping at something specific. One pattern I am looking for is duplicated drops initiated from the WAL records, when wraparound hits, or at least if there's a window small enough that two WAL records are generated and attempt to generate the same entry drop. That's just an assumption at this stage. > Is it enough to upgrade the replicas or we need to upgrade the primary as > well? That would be both. There are always reasons to update to the latest minor version of Postgres. See the release notes for a bunch of them, that's usually convincing enough especially with CVEs addressed. :) -- Michael
signature.asc
Description: PGP signature
