On Tue, Aug 20, 2024 at 9:00 AM Amit Langote <amitlangot...@gmail.com> wrote: > I think we'd modify plancache.c to postpone the locking of only > prunable relations (i.e., partitions), so we're looking at only a > handful of concurrent modifications that are going to cause execution > errors. That's because we disallow many DDL modifications of > partitions unless they are done via recursion from the parent, so the > space of errors in practice would be smaller compared to if we were to > postpone *all* cached plan locks to ExecInitNode() time. DROP INDEX > a_partion_only_index comes to mind as something that might cause an > error. I've not tested if other partition-only constraints can cause > unsafe behaviors.
This seems like a valid point to some extent, but in other contexts we've had discussions about how we don't actually guarantee all that much uniformity between a partitioned table and its partitions, and it's been questioned whether we made the right decisions there. So I'm not entirely sure that the surface area for problems here will be as narrow as you're hoping -- I think we'd need to go through all of the ALTER TABLE variants and think it through. But maybe the problems aren't that bad. It does seem like constraints can change the plan. Imagine the partition had a CHECK(false) constraint before and now doesn't, or something. -- Robert Haas EDB: http://www.enterprisedb.com
