Re: BF mamba failure

On Tue, Sep 16, 2025 at 02:45:03PM +0300, Kouber Saparev wrote:
> На пт, 12.09.2025 г. в 3:37 Michael Paquier <michael(at)paquier(dot)xyz> написа:
>> 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