On 13 April 2017 at 01:57, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:
> However I think it worth of quick research whether it is possible to create special
> code path for COPY in which errors don’t cancel transaction.
Not really. Anything at any layer of the system expects to be able to ERROR:
* datatype input functions
* CHECK constraints
* FK constraints
* unique indexes
* user defined functions run by triggers
* interrupt signalling (think deadlock detector)
* ...
and we rely on ERROR unwinding any relevant memory contexts, releasing
lwlocks, etc.
When an xact aborts it may leave all sorts of mess on disk. Nothing
gets deleted, it's just ignored due to an aborted xmin.
Maybe some xid burn could be saved by trying harder to pre-validate
batches of data as much as possible before we write anything to the
heap, sorting obviously faulty data into buffers and doing as much
work as possible before allocating a new (sub)xid and writing to the
heap. We'd still abort but we'd only be aborting a vtxid.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services