I've been reviewing ff9618e lately, and I'm wondering whether it has the same problem that 19de0ab solved. Specifically, ff9618e introduces has_partition_ancestor_privs(), which is used to check whether a user has MAINTAIN on any partition ancestors. This involves syscache lookups, and presently this function does not take any relation locks. I did spend some time trying to induce cache lookup errors, but I didn't have any luck. However, unless this can be made safe without too much trouble, I think I'm inclined to partially revert ff9618e, leaving the TOAST-related parts intact.
By reverting the partition-related parts of ff9618e, users would need to have MAINTAIN on the partition itself to perform the maintenance command. MAINTAIN on the partitioned table would no longer be sufficient. This is more like how things work on supported versions today. Privileges are checked for each partition, so a command that flows down to all partitions might refuse to process a partition (e.g., if the current user doesn't own the partition). In the future, perhaps we could reevaluate adding these partition ancestor privilege checks, but I'd rather leave it out for now instead of introducing behavior in v16 that is potentially buggy and difficult to remove post-GA. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com