Re: Do not lock tables in get_tables_to_repack

Hi,

On Fri, Jul 10, 2026 at 9:03 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> > While looking at it I also realized that get_tables_to_repack_partitioned
> > is likewise not careful enough about it: we do IndexGetRelation(, false)
> > which fails hard if the pg_index tuple cannot be found, which is the
> > wrong thing to do.

Agreed. For a single-level partitioned table, dropping a leaf blocks
on the parent's AccessExclusiveLock, which REPACK holds, so the leaf
can't go away mid-build. But for a multi-level table, REPACK holds a
lock only on the top parent, so a lower-level leaf whose immediate
parent is an intermediate table isn't protected and can be dropped
concurrently. So IndexGetRelation(, false) failing hard there is
indeed the wrong thing.

> > At the same time, it's annoying that half of the code that clearly
> > belongs in that routine is actually in ExecRepack(). I moved that to
> > where it rightfully belongs.

+1, that's a good cleanup. That code clearly belongs in
get_tables_to_repack_partitioned().

>> (The only somewhat annoying thing is that
> > we have to NULL-out the Relation pointer after returning; but that's not
> > *too* bad IMO.)

That's fine. We already NULL out rel after
get_tables_to_repack_partitioned() today, so the patch isn't adding
anything new there. Relying on a non-NULL return from
process_single_relation() to mean partitioned table is a little
indirect on first read, but the comments explains it well, and I
wouldn't complicate the code to avoid it.

> > Any opinions on this?
>
> I will take a closer look at this in a bit.

Patch looks good to me. One nit:

+ table_oid = IndexGetRelation(child_oid, true);
+ if (!OidIsValid(table_oid))
+ continue;

How about a short comment on why this is needed even with a lock on
the parent, since that lock doesn't cover lower-level leaves in a
multi-level partition tree?

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com