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@paquier.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