> 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.
v5-0001-Warn-when-REPACK-or-CLUSTER-skips-a-foreign-table.patch
Description: Binary data
