Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

On 3 March 2018 at 13:08, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com
> wrote:

> On 1/22/18 21:33, Craig Ringer wrote:
> > We don't have much in the way of rules about what input functions can or
> > cannot do, so you can't assume much about their behaviour and what must
> > / must not be cleaned up. Nor can you just reset the state in a heavy
> > handed manner like (say) plpgsql does.
>
> I think one thing to try would to define a special kind of exception
> that can safely be caught and ignored. Then, input functions can
> communicate benign parse errors by doing their own cleanup first, then
> throwing this exception, and then the COPY subsystem can deal with it.
>

That makes sense. We'd only use the error code range in question when it
was safe to catch without re-throw, and we'd have to enforce rules around
using a specific memory context. Of course no LWLocks could be held, but
that's IIRC true when throwing anyway unless you plan to proc_exit() in
your handler.

People will immediately ask for it to handle RI errors too, so something
similar would be needed there. But frankly, Pg's RI handling for bulk
loading desperately needs a major change in how it works to make it
efficient anyway, the current model of individual row triggers is horrible
for bulk load performance.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services