Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
От | torikoshia |
---|---|
Тема | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |
Дата | |
Msg-id | 769423519e16d18a1e7611c6931da58b@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) (Damir Belyalov <dam.bel07@gmail.com>) |
Ответы |
Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: