Re: Add new error_action COPY ON_ERROR "log"

On Fri, Jan 26, 2024 at 12:42 AM torikoshia <torikoshia@oss.nttdata.com> wrote:
>
> Hi,
>
> As described in 9e2d870119, COPY ON_EEOR is expected to have more
> "error_action".
> (Note that option name was changed by b725b7eec)
>
> I'd like to have a new option "log", which skips soft errors and logs
> information that should have resulted in errors to PostgreSQL log.
>
> I think this option has some advantages like below:
>
> 1) We can know which number of line input data was not loaded and
> reason.
>
>    Example:
>
>    =# copy t1 from stdin with (on_error log);
>    Enter data to be copied followed by a newline.
>    End with a backslash and a period on a line by itself, or an EOF
> signal.
>    >> 1
>    >> 2
>    >> 3
>    >> z
>    >> \.
>    LOG:  invalid input syntax for type integer: "z"
>    NOTICE:  1 row was skipped due to data type incompatibility
>    COPY 3
>
>    =# \! tail data/log/postgresql*.log
>    LOG:  22P02: invalid input syntax for type integer: "z"
>    CONTEXT:  COPY t1, line 4, column i: "z"
>    LOCATION:  pg_strtoint32_safe, numutils.c:620
>    STATEMENT:  copy t1 from stdin with (on_error log);
>
>
> 2) Easier maintenance than storing error information in tables or
> proprietary log files.
> For example, in case a large number of soft errors occur, some
> mechanisms are needed to prevent an infinite increase in the size of the
> destination data, but we can left it to PostgreSQL's log rotation.
>
>
> Attached a patch.
> This basically comes from previous discussion[1] which did both "ignore"
> and "log" soft error.
>
> As shown in the example above, the log output to the client does not
> contain CONTEXT, so I'm a little concerned that client cannot see what
> line of the input data had a problem without looking at the server log.
>
>
> What do you think?
>

I doubt the following part:
      If the <literal>log</literal> value is specified,
      <command>COPY</command> behaves the same as
<literal>ignore</literal>, exept that
      it logs information that should have resulted in errors to
PostgreSQL log at
      <literal>INFO</literal> level.

I think it does something like:
When an error happens, cstate->escontext->error_data->elevel will be ERROR
you manually change the cstate->escontext->error_data->elevel to LOG,
then you call ThrowErrorData.

but it's not related to `<literal>INFO</literal> level`?
my log_min_messages is default, warning.