From: | Masahiko Sawada <sawada(dot)mshk(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 tuples_skipped to pg_stat_progress_copy |
Date: | 2024-01-17 05:47:49 |
Message-ID: | CAD21AoCCF_K9zFKROhp6Mf3Q4HoUCcWP2=MEqadZsZtjU36TdA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 17, 2024 at 2:22 PM torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> wrote:
>
> Hi,
>
> 132de9968840c introduced SAVE_ERROR_TO option to COPY and enabled to
> skip malformed data, but there is no way to watch the number of skipped
> rows during COPY.
>
> Attached patch adds tuples_skipped to pg_stat_progress_copy, which
> counts the number of skipped tuples because source data is malformed.
> If SAVE_ERROR_TO is not specified, this column remains zero.
>
> The advantage would be that users can quickly notice and stop COPYing
> when there is a larger amount of skipped data than expected, for
> example.
>
> As described in commit log, it is expected to add more choices for
> SAVE_ERROR_TO like 'log' and using such options may enable us to know
> the number of skipped tuples during COPY, but exposed in
> pg_stat_progress_copy would be easier to monitor.
>
>
> What do you think?
+1
The patch is pretty simple. Here is a comment:
+ (if <literal>SAVE_ERROR_TO</literal> is specified, otherwise zero).
+ </para></entry>
+ </row>
To be precise, this counter only advances when a value other than
'ERROR' is specified to SAVE_ERROR_TO option.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2024-01-17 06:10:01 | Re: index prefetching |
Previous Message | Michael Paquier | 2024-01-17 05:47:33 | Assertion failure with epoch when replaying standby records for 2PC |