> Especially when an index is specified, the patch adds another
> find_all_inheritors() call and loop while holding AccessExclusiveLock on
> the parent. Is this overhead unnoticeable and acceptable for tables
> with many small partitions?
After taking another look I think it's the opposite: we can avoid
another find_all_inheritors with plain REPACK, but we need at least
some find_inheritance_children calls for USING INDEX / CLUSTER as
foreign partitions don't have indexes.
v5 is this alternative approach (adding the warning inside
get_tables_to_repack_partitioned). I tried to measure them, but I
couldn't measure any difference between the two, only noise.
> So a partition can be dropped concurrently while warnings are being
> issued for foreign partitions, and get_rel_name(tableoid) can return NULL
> before the warning is emitted.
Oops, I missed that nested partitions can do this because we only lock
the top level parent. So yes, that null check is needed.
And because of this, I started thinking about why
find_all_inheritors(..., NoLock, ...) works at all with multi level
partition tables (root-parent-parent2-child) against a concurrent drop
of parent2 with only root locked... and it doesn't. That's an existing
race in vacuum/analyze/repack and lock table, I'll start a separate
thread about it tomorrow.
