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