On Sat, Mar 8, 2025 at 11:57 AM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2025-Mar-07, Álvaro Herrera wrote:
>
> > I tested this, because of a refactoring suggestion [1] and I find that
> > it's rather completely broken.
>
> I think we need significantly more complex scheduling code if we want
> this to actually work, possibly even having to hack the ParallelSlot
> API some, so that we can inspect which tables have a running reindex and
> know not to schedule the next one on it. What we're doing now makes no
> sense.
>
> We should strike this out from the list of features of 17 and revert
> this commit.
>
> If we want this feature in 19, we need another go through the drawing
> board. (There's clearly not enough time to do it for 18.)
Yes, I also think we need to revert this from 17. One thing to care
about: it might be already used in some user scripts. Should we
replace pg_fatal() with some notice and then run in a single job? So,
user scripts wouldn't error out.
------
Regards,
Alexander Korotkov
Supabase
