Re: BF mamba failure

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Kouber Saparev <kouber(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: BF mamba failure
Date: 2026-07-08 22:45:54
Message-ID: ak7TIsbToN2iMs4K@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 08, 2026 at 10:53:47AM +0000, Bertrand Drouvot wrote:
> So given that Kouber said that "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.", OID reused is likely the culprit (
> doable in months at this rate).

That would mean keeping around a session on the standby for long time.
With a connection pooler, why not.

> The good news is that it does not reproduce on the 17 STABLE branch, I guess it's
> due to 850b9218c8e being backpatched to stable branches. So a fix will be in the
> next minor versions.

Due to the decision of using missing_ok=true in the end-of-transaction
drops, that could indeed help. I'd be curious to hear back after the
next minor release. If I have nothing more to do, I'll take it.

> Michael, I wonder if that would make sense to add this "set_next_oid" kind of
> thing to a contrib module to test this kind of OID reuse issue. Same idea as
> xid_wraparound.

That's probably larger than just the OIDs. Maybe something that's
able to do what pg_resetwal does for the control file could be useful.
Publishing another footgun sounds a bit annoying, but we also have
stuff like pg_surgery, that serve a similar purpose to shortcut the
backend.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2026-07-08 22:50:24 Re: SPLIT/MERGE use of is_internal=true
Previous Message Tomas Vondra 2026-07-08 22:14:03 Re: index prefetching