Thanks for all the help, and a couple of offlist suggestions.
We have fixed the problem by copying all of the data (160GB) to a partitioned table, replacing the trigger with table column defaults for timestamp and sequence values.
Simon Windsor <simon.windsor@cornfield.me.uk> writes: > Since then, large bulk inserts of configuration changes are failing with > this Error, but adhoc and small changes are working ok.
Might it be that things work as long as the trigger is only tasked with redirecting to the same child table (or limited set of child tables) within a particular insertion command?
I'm wondering if this could be related to bug #15913 --- which I just fixed today, so maybe I just have it on the brain too much. The manifestation doesn't look quite the same, but given the way your trigger is written, something about NEW.* changing type from one call to the next might have something to do with it.
I also wonder how often you create/delete child tables.