Re: Allow progress tracking of sub-commands

Hi Antonin,

Thanks for suggesting enhancements to the progress reporting framework.

I have comments on the solution's approach.

/*
+ * Some commands have a sub-command, e.g. REPACK (re)builds indexes. The
+ * target can be different, e.g. when the sub-command builds an index on
+ * TOAST relation.
+ */
+ ProgressCommandType st_progress_command2;
+ Oid st_progress_command_target2;
+ int64 st_progress_param2[PGSTAT_NUM_PROGRESS_PARAM];

This approach only works for a nesting depth of 2, not for 3 or more
levels of subcommands, for instance.
I am not aware of a concrete example of such a command but I think we should
keep the design generic enough to accommodate this.

Shall we consider reporting the progress counters of a sub-command as
additional parameters
in the existing st_progress_param[] array? A top level command can
define the progress parameters
based on the number and type of sub-commands it expects to see. This
way we can even restrict or alter the counters we would like to report
for a sub-command. This also avoids changing PgBackendStatus every
time we encounter a command requiring deeper nesting levels.

Thank you,
Rahila Syed

On Mon, 29 Jun 2026 at 19:57, Antonin Houska <ah(at)cybertec(dot)at> wrote:
>
> I've noticed several complaints about two commands trying to report their
> progress at the same time, overwriting each other's output [1][2][3]. I posted
> a prototype of an enhancement of the monitoring infrastructure that allows for
> progress reporting of two commands w/o conflicts [4].
>
> This is a new version that passes regression tests. I'll register it for the
> upcoming CF.
>
>
> [1] https://www.postgresql.org/message-id/5667.1774513434%40localhost
> [2] https://www.postgresql.org/message-id/CALj2ACUgwSchK6jQ2CdKLBWUADTOE_zKdTff2Zg3E6hOuXKv-w%40mail.gmail.com
> [3] https://www.postgresql.org/message-id/aj4gJQMba0kClQmj%40Mac
> [4] https://www.postgresql.org/message-id/30939.1777888333%40localhost
>
> --
> Antonin Houska
> Web: https://www.cybertec-postgresql.com
>