Re: Allow progress tracking of sub-commands

Alberto Piai <alberto(dot)piai(at)gmail(dot)com> wrote:

> On Wed Jul 22, 2026 at 10:28 AM CEST, Antonin Houska wrote:
> >>
> >> @@ -33,9 +37,30 @@ pgstat_progress_start_command(ProgressCommandType cmdtype, Oid relid)
> >> return;
> >> What do you think, is something like this feasible? Maybe it would
> >> address Rahila's point, while not being too much extra work / complex
> >> code.
> >
> > Yes, I think it's worth at least a prototype. Do you want to adjust my patch
> > yourself or should I do?
>
> Please go on, I was just trying to help as a reviewer. Looking forward
> to the second version then :)

I could finally get back to it, and tried a different approach. If a
sub-command start its progress reporting, the backend saves the state of the
original ("parent") command and lets the sub-command publish its progress
information instead. If the sub-command starts another one, another state is
pushed on to a stack. Thus the "nesting level" is basically unlimited.

Unlike the previous patch, the parent command does not appear in the progress
reporting views while the sub-command is running. This way we don't need to
increase the per-backend amount of shared memory. I'm not sure this is a
serious limitation: when the sub-command is running, the parent command is
only waiting for its completion, so the parent's progress info does not
change. We could perhaps report ids/names of all the "ancestor" commands, so
that user knows that e.g. CREATE INDEX was launched by REPACK. What do you
think?

--
Antonin Houska
Web: https://www.cybertec-postgresql.com