On Tue, Nov 29, 2022 at 06:13:56PM -0500, Tom Lane wrote:
> Greg Stark <stark@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 <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Embrace your flaws. They make you human, rather than perfect,
which you will never be.
