Re: Fix reindexdb with parallel index-level conrurrent run

From: Manu <manuelreyesbravo(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fix reindexdb with parallel index-level conrurrent run
Date: 2026-10-05 19:42:21
Message-ID: 179122934183.429794.212586221593626226@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Michael,

> so I'd wonder about just returning an error first

Agreed. The only case that fails is two or more of the named indexes
sharing a table with -j >= 2 (they batch into one multi-statement query).
And for that case --jobs cannot parallelize anyway: the indexes of one
table have to be reindexed one at a time to avoid deadlocks. So fixing the
parallel path unlocks no speed, it only removes the error. Erroring out
looks right to me; a clear message would beat today's "cannot run inside a
transaction block". Happy to write that.

Regards,
Manu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Burd 2026-10-05 19:49:29 Re: UNDO with constant time recovery (CTR)
Previous Message Greg Burd 2026-10-05 19:36:36 Re: UNDO with constant time recovery (CTR)