Re: Fast COPY FROM based on batch insert - Mailing list pgsql-hackers

From Andrey Lepikhov
Subject Re: Fast COPY FROM based on batch insert
Date
Msg-id 9b293a07-c822-a326-6ff2-4a9e0e9e5549@postgrespro.ru
Whole thread Raw
In response to Re: Fast COPY FROM based on batch insert  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Responses Re: Fast COPY FROM based on batch insert
List pgsql-hackers
On 8/9/22 16:44, Etsuro Fujita wrote:
>>> -1 foo
>>> 1 bar
>>> \.
> ERROR:  new row for relation "t1" violates check constraint "t1_f1positive"
> DETAIL:  Failing row contains (-1, foo).
> CONTEXT:  remote SQL command: INSERT INTO public.t1(f1, f2) VALUES
> ($1, $2), ($3, $4)
> COPY ft1, line 3
> 
> In single-insert mode the error context information is correct, but in
> batch-insert mode it isn’t (i.e., the line number isn’t correct).
> 
> The error occurs on the remote side, so I'm not sure if there is a
> simple fix.  What I came up with is to just suppress error context
> information other than the relation name, like the attached.  What do
> you think about that?
I've spent many efforts to this problem too. Your solution have a 
rationale and looks fine.
I only think, we should add a bit of info into an error report to 
simplify comprehension why don't point specific line here. For example:
'COPY %s (buffered)'
or
'COPY FOREIGN TABLE %s'

or, if instead of relname_only field to save a MultiInsertBuffer 
pointer, we might add min/max linenos into the report:
'COPY %s, line between %llu and %llu'

-- 
Regards
Andrey Lepikhov
Postgres Professional



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Tab completion for "ALTER TYPE typename SET" and rearranged "Alter TYPE typename RENAME"
Next
From: Thomas Munro
Date:
Subject: Header checker scripts should fail on failure