On Tue, May 24, 2022 at 12:37 PM Matthias van de Meent < boekewurm+postg...@gmail.com> wrote:
> On Tue, 24 May 2022 at 19:13, Zhihong Yu <z...@yugabyte.com> wrote: > > > > Hi, > > Please see attached for enhancement to COPY command progress. > > > > The added status column would allow users to get the status of the most > recent COPY command. > > I fail to see the merit of retaining completed progress reporting > commands in their views after completion, other than making the > behaviour of the pg_stat_progress-views much more complicated and > adding overhead in places where we want the system to have as little > overhead as possible. > > Trying to get the status of a COPY command after it finished on a > different connection seems weird, as that other connection is likely > to have already disconnected / started another task. To be certain > that a backend can see the return status of the COPY command, you'd > have to be certain that the connection doesn't run any other > _progress-able commands in the following seconds / minutes, which > implies control over the connection, which means you already have > access to the resulting status of your COPY command. > > Regarding the patch: I really do not like that this leaks entries into > all _progress views: I get garbage data from e.g. the _create_index > and _copy views when VACUUM is running, etc, because you removed the > filter on cmdtype. > Also, the added fields in CopyToStateData / CopyFromStateData seem > useless when a pgstat_progress_update_param in the right place should > suffice. > > Kind regards, > > Matthias van de Meent > Hi, For #2 above, can you let me know where the pgstat_progress_update_param() call(s) should be added ? In my patch, pgstat_progress_update_param() is called from error callback and EndCopy(). For #1, if I use param18 (which is not used by other views), would that be better ? Thanks
