Re: BF mamba failure

We had this issue again, the database just stopped - PostgreSQL 17.6.

FATAL,XX000,"trying to drop stats entry already dropped: kind=relation
dboid=16420 objoid=3885511363 refcount=1 generation=0"

There is no such object present in the database.

Do you think the issue might be fixed in PostgreSQL 18.4?... Or PostgreSQL
19 eventually?

На ср, 17.09.2025 г. в 6:33 Michael Paquier <michael@paquier.xyz> написа:

> 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
>