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