Re: Fix reindexdb with parallel index-level conrurrent run

On Fri, Oct 02, 2026 at 10:03:39PM +0500, Kirill Reshke wrote:
> The root cause is that reindexdb tries to parallelize REINDEX by
> batching all commands related to one table in one job. However,
> implementation of this makes multiple DDL query an multistatement
> which is transformed into implicit transaction server-side.
>
> Oversight of 47f99a407d. I didn't find any related bug report, so it
> looks like this feature is not widely used. affected versions and
> 17-19 and master.

Sending such commands one-by-one also makes me think that we should
have some smarter parallel queuing, but I don't really know how much
better we could do on top of what's already in the tree. For the
parallel index-level non-concurrent case, we already order the
commands so as the same table is not worked on at the same time across
multiple slots to avoid conflicts.

Duplicating run_reindex_command() to be called in these three
different code branches vs once previously puts the code in a worse
state. On HEAD, we have one or more gen_reindex_command() for each
branch, wrapped by one single run_reindex_command(). Perhaps the
result would be nice if we rethink the gen/run interfaces, just that
the succession of two gen/run_reindex_command calls does not give me a
warm feeling: it makes the reasoning of the gen/run steps harder to
think about.

Btw, my first impression was: is there a huge use case for the support
of this kind of mode anyway? When running under CONCURRENTLY at index
level, parallel jobs have limited interest as the wait phases could
take a long time, so I'd wonder about just returning an error first,
and rethink better the code to support this case. Finally, perhaps
all that is not really worth the effort, especially because
table-level concurrent works (er, right?).
--
Michael