From: Antonin Houska <ah@cybertec.at>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
    Matthias van de Meent <boekewurm+postgres@gmail.com>,
    Pg Hackers <pgsql-hackers@lists.postgresql.org>,
    Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
In-reply-to: <5667.1774513434@localhost>
References: 
 <CAFC+b6qk3-DQTi43QMqvVLP+sudPV4vsLQm5iHfcCeObrNaVyA@mail.gmail.com>
 <202603191855.fzsgsnyzfvpt@alvherre.pgsql>
 <CADzfLwURy8_BYyqrvr6rhTXsW3=5QMRLHuNati3CgY0nKRSwyw@mail.gmail.com>
 <5667.1774513434@localhost>
Comments: In-reply-to Antonin Houska <ah@cybertec.at>
   message dated "Thu, 26 Mar 2026 09:23:54 +0100."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <90699.1774627975.1@localhost>
Date: Fri, 27 Mar 2026 17:12:55 +0100
Message-ID: <90700.1774627975@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/90700.1774627975%40localhost>
Precedence: bulk

Antonin Houska <ah@cybertec.at> wrote:

> Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:

> > src/backend/catalog/index.c:766,1464-1469
> > 
> > "bool      progress = (flags & INDEX_CREATE_REPORT_PROGRESS) != 0;"
> > 
> > AFAIU gin, hash and btree (at least) still just unconditionally write
> > PROGRESS_CREATEIDX_* progress.
> 
> I think you're right, I'll check it.

I concluded this is a problem that exists for quite a while and should be
fixed separately. Currently I don't see conflicts of parameter indexes between
PROGRESS_COMMAND_REPACK and PROGRESS_COMMAND_CREATE_INDEX. There would be some
if the index was built with the CONCURRENTLY option, but REPACK uses normal
index build.

I tried to write a patch that allows progress tracking of two commands at the
same time (a "main command" and a "subcommand"), but regression tests revealed
that contrib/file_fdw is broken in a way that I could not fix easily: during
execution of a join, two COPY FROM commands are executed at the same time and
they overwrite the status of each other. Unlike the concept of a sub-command,
we cannot assume here that the command that started the reporting as the
second will stop as the first. Thus in pgstat_progress_end_command() we cannot
figure out which node is trying to stop the reporting.

It needs more work, I can get back to it after PG 19 feature freeze.

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