Re: Allow progress tracking of sub-commands

Hi Antonin,

On Fri, Nov 13, 2026 at 7:35 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> In [1] I tried a different approach: only the progress of the actually running
> command is displayed, while there's no limit on the nesting level. What do you
> think about that?

The stack works until an error hits a nested command. I sampled
the views every ~0.5 ms on 77bba5454f9 with and without your 0001
(asserts on and off); script and results attached.

It fixes ANALYZE of a file_fdw table and a CREATE INDEX whose index
function catches an error (master shows no ANALYZE or CREATE INDEX
row there); the three-level case from my last mail no longer asserts.

But when a COPY fails under another COPY, or a PL/pgSQL block catches a
COPY's error, a COPY row stays and hides a later CREATE INDEX
(indexcmds.c:646). AbortTransaction() ends one level (xact.c:2910);
pgstat_progress_depth() skips the running command and returns 0 with one
parent (backend_progress.c:260), so the subtransaction abort ends
nothing (xact.c:5370). 10,000 COPYs failing under another COPY added
2.7 MB to TopMemoryContext. Counting the running command and ending all
levels on abort fixed both (make check passes).

On hiding the parent: during REPACK of a 2M-row table with three
indexes, pg_stat_progress_repack had no row in 80-90% of the samples
(master: under 3%); pg_stat_progress_create_index showed REINDEX on
that table. Same for CLUSTER and VACUUM FULL.

> Regarding the file_fdw problem, I don't have a good idea how to fix it: if
> contents of two or more tables is being merge-joined, there are two or more
> COPY commands running at the same time. So similar to the previous version,
> the patch at least disables progress reporting if file_fdw is involved.

The flag outlives the statement: after one with two file_fdw scans
fails or is cancelled, pgstat_track_progress stays false
(file_fdw.c:724), and CREATE INDEX, VACUUM, ANALYZE and COPY in that
session show no row. Counted at plan time (file_fdw.c:634), it also
hides every second one-scan statement, and stops covering a two-scan
generic plan after its first EXECUTE. Counting the scans of the
executing plan, with abort callbacks, fixed those here.

Manu