Re: adding status for COPY progress report

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Zhihong Yu <zyu(at)yugabyte(dot)com>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: adding status for COPY progress report
Date: 2022-05-26 00:51:04
Message-ID: Yo7O+G9sN0fkdOQJ@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 25, 2022 at 09:34:51AM -0700, Zhihong Yu wrote:
> Let's look at the sequences of user activity for long running COPY command.
> The user would likely issue queries to pg_stat_progress_copy over time.
> Let's say on Nth invocation, the user sees X tuples copied.
> On (N+1)st invocation, the view returns nothing.
> The user knows that the COPY may have completed - but did the operation
> succeed or end up with some error ?

If I am following this thread correctly and after reading the patch,
that's what the status code of the connection issuing the command is
here for. You have no guarantee either that the status you are trying
to store in the progress view is not going to be quickly overwritten
by a follow-up command, making the window where this information is
available very small in most cases, limiting its value. The window
gets even smaller if the connection that failed the COPY is used in a
connection pooler by a different command.

The changes in pgstat_progress_end_command() and
pg_stat_get_progress_info() update st_progress_command_target
depending on the command type involved, breaking the existing contract
of those routines, particularly the fact that the progress fields
*should* be reset in an error stack.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Japin Li 2022-05-26 01:02:08 Re: Invalid memory alloc request size for repeat()
Previous Message Andres Freund 2022-05-26 00:47:31 Re: [RFC] building postgres with meson