public inbox for [email protected]
help / color / mirror / Atom feedFrom: Kouber Saparev <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Bertrand Drouvot <[email protected]>
Cc: [email protected]
Subject: Re: BF mamba failure
Date: Tue, 7 Jul 2026 13:13:59 +0300
Message-ID: <CAN4RuQv2tk6ELko_M8YC6eM1YgV1Z2r-Lht22b0ObCTPTTG5Aw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CAN4RuQvYth942J2+FcLmJKgdpq6fE5eqyFvb_PuskxF2eL=Wzg@mail.gmail.com>
<[email protected]>
<CAN4RuQt_Sr9h2NG0-fr7XSmU=DeHkzTeysCuOAWhWrkuhw8Puw@mail.gmail.com>
<CAN4RuQs6ht4T7ph8NbxHZ+NmDmTrvczAxpyZmcqk+74tzsciuw@mail.gmail.com>
<[email protected]>
<CAN4RuQv3OTJ1Owqn2U+7ZbvL-N-nZYAUjF_NG8o12ayFN-=0GQ@mail.gmail.com>
<[email protected]>
<CAN4RuQvQ3ATcYvfTR1LzJnUJXpo_F8mgz-+WxoZsyusLLmCwYA@mail.gmail.com>
<[email protected]>
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 <[email protected]> написа:
> 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
>
view thread (20+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: BF mamba failure
In-Reply-To: <CAN4RuQv2tk6ELko_M8YC6eM1YgV1Z2r-Lht22b0ObCTPTTG5Aw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox