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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling
Дата
Msg-id 29493.1520056106@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] GSOC'17 project introduction: Parallel COPY executionwith errors handling  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: [HACKERS] GSOC'17 project introduction: Parallel COPY executionwith errors handling  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: psql tab completion for ALTER INDEX SET
Следующее
От: konstantin knizhnik
Дата:
Сообщение: Re: Cached/global query plans, autopreparation