On Tue, Nov 29, 2022 at 06:13:56PM -0500, Tom Lane wrote: > Greg Stark <st...@mit.edu> writes: > > If I understand correctly you're going to insert into the local index > > for the partition using the normal btree uniqueness implementation. > > Then while holding an exclusive lock on the index do lookups on every > > partition for the new key. Effectively serializing inserts to the > > table? > > ... not to mention creating a high probability of deadlocks between > concurrent insertions to different partitions. If they each > ex-lock their own partition's index before starting to look into > other partitions' indexes, it seems like a certainty that such > cases would fail. The rule of thumb about locking multiple objects > is that all comers had better do it in the same order, and this > isn't doing that.
I am not sure why they would need to exclusive lock anything more than the unique index entry they are adding, just like UPDATE does. > I still think this is a dead end that will never get committed. > If folks want to put time into perhaps finding an ingenious > way around these problems, okay; but they'd better realize that > there's a high probability of failure, or at least coming out > with something nobody will want to use. Agreed, my earlier point was that this would need a lot of thought to get right since we don't do this often. The exclusion constraint is a close example, though that is in a single index. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Embrace your flaws. They make you human, rather than perfect, which you will never be.
