Hello hackers, I was reviewing the COPY ON_ERROR_TABLE patch and had a few implementation questions that may be worth considering.
- The COPY multi-insert path currently depends on CopyMultiInsertBuffer and table_multi_insert() batching behavior. Recovering from row-level failures while buffers are partially populated may complicate buffer consistency, trigger visibility, or index handling. - Would it make sense to initially disable multi-insert batching when ON_ERROR_TABLE is enabled (forcing CIM_SINGLE)? That seems like a simpler starting point for correctness and recovery semantics. - I was also curious about the intended transaction behavior for rejected rows. Should rows written to the error table rollback together with the surrounding COPY transaction if a later failure occurs? - Another possible edge case is recursive failure handling if insertion into the error table itself fails. I have not yet reproduced a concrete failure case, so these are currently review observations rather than confirmed issues. Thanks for working on this feature. Regards, Vellaipandiyan
