PL/pgSQL batch writes: cap a transaction by exception blocks (subtransactions), not by rows

A batch loader that writes N rows per transaction, each row inside a BEGIN ... EXCEPTION block so one bad row does not abort the batch, is usually capped at a fixed number of rows (e.g. 50) to stay under PostgreSQL's 64 cached subtransaction XIDs per backend. When one input line starts writing several records plus links between them, each in its own exception block, a 50-row batch can open 250+ subtransactions. Lookups by other sessions then slow down (subtrans overflow) with no error.

Count exception blocks, not rows. The per-line function returns how many blocks it actually opened (one per record written, one per link inserted). The batch function also computes an upper bound for the NEXT line from its input (objects present + linkable pairs). It stops before the line that could cross the cap (e.g. 50), and always processes at least one line. It returns results only for the lines it processed, and the caller moves its cursor to the last processed line, in the same transaction. A single-record line still costs 1, so the old 50-rows-per-batch behaviour (and its tests) stays unchanged. Use one exception block per link (pair), so a failing link (limit trigger) rolls back only that link and not the records.

Every PL/pgSQL BEGIN...EXCEPTION block that writes gets its own subtransaction XID. Past 64 per transaction, the backend overflows its subxid cache and other sessions have to consult pg_subtrans to check visibility. With multi-record lines, the number of rows no longer measures that cost.