Also called: subxid overflow, suboverflowed backend, pg_subtrans contention
In plain English
Every backend can cache up to 64 of its own active subtransaction ids in shared memory. A subtransaction is created by a SAVEPOINT or a PL/pgSQL block with an EXCEPTION handler. Open more than 64 at once and the cache overflows: from then on, visibility checks for those transactions must look up the pg_subtrans SLRU on disk/cache instead of the fast in-memory array.
Why it matters
An overflowed backend forces other sessions to consult the shared pg_subtrans SLRU constantly, which under concurrency becomes a severe bottleneck — the well-known “subtransaction performance cliff”. Loops that open a savepoint (or exception block) per row are the classic cause. Keep concurrent subtransactions under 64 where possible.