Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling
Date
Msg-id 29493.1520056106@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] GSOC'17 project introduction: Parallel COPY executionwith errors handling  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] GSOC'17 project introduction: Parallel COPY executionwith errors handling  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Craig Ringer <craig@2ndquadrant.com> writes:
> On 3 March 2018 at 13:08, Peter Eisentraut <peter.eisentraut@2ndquadrant.com
> wrote:
>> 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.

I don't think that can possibly work.  It would only be safe if, between
the thrower and the catcher, there were no other levels of control
operating according to the normal error-handling rules.  But input
functions certainly cannot assume that they are only called by COPY,
so how could they safely throw a "soft error"?

            regards, tom lane


pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: psql tab completion for ALTER INDEX SET
Next
From: konstantin knizhnik
Date:
Subject: Re: Cached/global query plans, autopreparation