From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add new error_action COPY ON_ERROR "log" |
Date: | 2024-01-26 15:43:13 |
Message-ID: | CAKFQuwa8ZEmh0LAbdUY-oO3G+iN7nW8GDFNMNLw4Tq+s798scQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 25, 2024 at 9:42 AM torikoshia <torikoshia(at)oss(dot)nttdata(dot)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.
>
>
Seems like an easy win but largely unhelpful in the typical case. I
suppose ETL routines using this feature may be running on their machine
under root or "postgres" but in a system where they are not this very
useful information is inaccessible to them. I suppose the DBA could set up
an extractor to send these specific log lines elsewhere but that seems like
enough hassle to disfavor this approach and favor one that can place the
soft error data and feedback into user-specified tables in the same
database. Setting up temporary tables or unlogged tables probably is going
to be a more acceptable methodology than trying to get to the log files.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2024-01-26 15:48:31 | Re: MERGE ... WHEN NOT MATCHED BY SOURCE |
Previous Message | Robert Haas | 2024-01-26 15:41:05 | Re: POC: GROUP BY optimization |