Hi, On Fri, Jul 10, 2026 at 9:03 AM Bharath Rupireddy <[email protected]> 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
