On Wed, 20 Feb 2019 at 06:36, Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, Feb 18, 2019 at 6:15 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > I'm inclined to think that if we already have lock on the parent > > partitioned table (thereby, IIUC, guaranteeing that its partitioning > > info can't change) that the order in which we acquire the same lock > > level on its partition(s) isn't very important. > > Well, as it turns out, there's also a pending patch (series) to remove > that guarantee which I would like to get committed. The thread for > that is "ATTACH/DETACH PARTITION CONCURRENTLY". I believe I've more > or less got the issues with that patch sorted out, but I'm concerned > about how it interacts with all of the other things that are currently > in flight. Delaying or skipping lock acquisition in some cases and > weakeni ng the locks we take in others is not a process that can > continue indefinitely without at some point hitting a wall.
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. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
