On Tue, Feb 19, 2019 at 4:07 PM David Rowley <david.row...@2ndquadrant.com> wrote: > I'd say that here we should only discuss what this patch is doing, not > anything else that's in flight that you're concerned will conflict > with the ATTACH/DETACH PARTITION CONCURRENTLY patch. > > During INSERT and UPDATE, not all partitions will always be locked > before executor startup. This patch removing the find_all_inheritors() > call from ExecSetupPartitionTupleRouting() is not going to break > ATTACH/DETACH PARTITION CONCURRENTLY if it wasn't already broken in > the first place. With this patch, we're still obtaining locks after > execution has begun, it just may delay the locking until a bit later. > It was previously already happening after executor startup had begun, > so the window for the problems that you describe were already > non-zero.
The issue of whether it's OK to lock child partitions in variable order has come up on many different threads, and as far as I know this is the only thread where Tom has expressed any view on it. Since Tom is a smart guy,[1] I was hoping to get him to expand on those views a little bit. Even if that leads this thread to detour slightly from the matter immediately at hand, I think it will be worth it if it gets us to some kind of consensus on what has been a thorny question for some time now. On the other hand, Tom may not reply, in which case the rest of us will just have to keep faking it as best we can. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company [1] citation needed, except not really
