Subtransaction overflow (pg_subtrans)
Also called: subxid overflow, suboverflowed backend, pg_subtrans contention
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.
What this means
Each backend can keep up to 64 of its own active subtransaction ids in fast shared memory, a subtransaction being what a SAVEPOINT or a PL/pgSQL EXCEPTION block starts. Open more than 64 at once and that cache overflows; from then on, visibility checks have to hit the slower pg_subtrans log instead of the quick in-memory list.
Why it matters operationally
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.