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

From Peter Eisentraut
Subject Re: [HACKERS] GSOC'17 project introduction: Parallel COPY executionwith errors handling
Date
Msg-id 53988e1e-ce41-f3ca-f6af-c9e43428c0d3@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] GSOC'17 project introduction: Parallel COPY executionwith errors handling  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 3/3/18 00:48, Tom Lane wrote:
> 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"?

That assumes that throwing a soft error in a context that does not
handle it specially is not safe.  I'd imagine in such situations the
soft error just behaves like a normal exception.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Disabling src/test/[ssl|ldap] when not building with SSL/LDAPsupport
Next
From: Peter Eisentraut
Date:
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take two