MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 26 Sep 2022 22:04:36 +0900
From: torikoshia <torikoshia@oss.nttdata.com>
To: Damir Belyalov <dam.bel07@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 a.lepikhov@postgrespro.ru
Subject: Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
In-Reply-To: 
 <CALH1Lgsr7Asz6r6jnRta7DVEjKwyz=b3XJhyCMoYv8Yy9y4cXg@mail.gmail.com>
References: <1197371508.4255.1327.camel@ebony.site>
 <1197660423.1536.8.camel@dell.linuxdev.us.dell.com>
 <15007.1197674561@sss.pgh.pa.us>
 <200712141830.16877.trent_shipley@qwest.net>
 <87k31ftoe0.fsf_-_@commandprompt.com>
 <CAFj8pRC3ksKhaSxDUo3Y1DekvV12OcEERryT8gPGdUAVEe2SLg@mail.gmail.com>
 <CAFj8pRD9Pi9besMvv0Yo0A4wqQ-D=cBXGRQhz_oS+BNgv_41_Q@mail.gmail.com>
 <CALH1LgsKDk4XthrM4m8tAqfoPyNgDCSFV3Go1nevXze-8dwKrA@mail.gmail.com>
 <CAFj8pRC96C+C6Gg8OHkv26YZMQsrRJ9YtJhBKrrrje1hc2yrcw@mail.gmail.com>
 <CALH1LgvmNcnO8dYyckcEmiJ6PGDnpRWA3V1td1SDKzqt6FrMJw@mail.gmail.com>
 <e78a86704ab2b2b967f0d674e5a72643@oss.nttdata.com>
 <CALH1Lgu0dqsQUm9QYdoSvgu-O9Ac5OsbE3TxxZqChUrVF+Qrjw@mail.gmail.com>
 <dc876e926f284ee60eef4ece755fa419@oss.nttdata.com>
 <CALH1Lgv5QeYSWYDgMBd=wvKum8egiaMR-_77VGsiHPt7E8dK9Q@mail.gmail.com>
 <CALH1LgvzpORM+EHVXRz4-Dv+_aHvm9m9Hu6eYM4PfppwKgXvFQ@mail.gmail.com>
 <686e46d6718f9535bc39fac7cad7408b@oss.nttdata.com>
 <CALH1Lgsr7Asz6r6jnRta7DVEjKwyz=b3XJhyCMoYv8Yy9y4cXg@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <769423519e16d18a1e7611c6931da58b@oss.nttdata.com>
Archived-At: 
 <https://www.postgresql.org/message-id/769423519e16d18a1e7611c6931da58b%40oss.nttdata.com>
Precedence: bulk

On 2022-09-21 21:11, Damir Belyalov wrote:
Thanks for updating patch.

> In the previous patch there was an error when processing constraints.
> The patch was fixed, but the code grew up and became more complicated
> (0005-COPY_IGNORE_ERRORS). I also simplified the logic of
> safeNextCopyFrom().
> You asked why we need subtransactions, so the answer is in this patch.
> When processing a row that does not satisfy constraints or INSTEAD OF
> triggers, it is necessary to rollback the subtransaction and return
> the table to its original state.
> Cause of complexity, I had to abandon the constraints, triggers
> processing in and handle only errors that occur when reading the file.
> Attaching simplified patch (0006-COPY_IGNORE_ERRORS).

Do you mean you stop dealing with errors concerned with constraints and 
triggers and we should review 0006-COPY_IGNORE_ERRORS?

> Tried to implement your error and could not. The result was the same
> as COPY FROM implements.

Hmm, I applied v6 patch and when canceled COPY by sending SIGINT(ctrl + 
C), I faced the same situation as below.
I tested it on CentOS 8.4.

   =# COPY test FROM '/home/tori/pgsql/master/10000000.data' WITH 
(IGNORE_ERRORS);
   ^CCancel request sent
   ERROR:  canceling statement due to user request
   CONTEXT:  COPY test, line 628000: "628000       xxx"

   =# SELECT 1;
   ERROR:  current transaction is aborted, commands ignored until end of 
transaction block

  =# ABORT;
   FATAL:  UserAbortTransactionBlock: unexpected state STARTED
   server closed the connection unexpectedly
           This probably means the server terminated abnormally
           before or while processing the request.
   The connection to the server was lost. Attempting reset: Succeeded.

I did the same procedure on COPY FROM without IGNORE_ERRORS and didn't 
face this situation.

-- 
Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION