Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
torikoshia <torikoshia@oss.nttdata.com>
From: torikoshia <torikoshia@oss.nttdata.com>
To: Damir Belyalov <dam.bel07@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
a.lepikhov@postgrespro.ru
Date: 2022-09-26T13:04:36Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
doc: Fix COPY ON_ERROR option syntax synopsis.
- f6f8ac8e75c9 17.0 landed
-
Disallow specifying ON_ERROR option without value.
- a6d0fa5ef840 17.0 landed
-
Rename COPY option from SAVE_ERROR_TO to ON_ERROR
- b725b7eec431 17.0 landed
-
Fix spelling in notice
- 58fbbc9d683c 17.0 landed
-
Add new COPY option SAVE_ERROR_TO
- 9e2d8701194f 17.0 landed
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