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
signature.asc
Description: PGP signature
