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 <[email protected]> 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 >
