On Tue, Nov 29, 2022 at 09:16:23PM -0500, Tom Lane wrote: > Assuming that you are inserting into index X, and you've checked > index Y to find that it has no conflicts, what prevents another > backend from inserting a conflict into index Y just after you look? > AIUI the idea is to prevent that by continuing to hold an exclusive > lock on the whole index Y until you've completed the insertion. > Perhaps there's a better way to do that, but it's not what was > described.
As I understood it, you insert into index X and then scan all other indexes to look for a conflict --- if you find one, you abort with a unique index conflict. Other index changes do the same. So, for example, one session inserts into index X and then scans all other indexes. During the index scan, another session inserts into index Y, but its scan sees the index X addition and gets a uniqueness conflict error. > I actually think that that problem should be soluble with a > slightly different approach. The thing that feels insoluble > is that you can't do this without acquiring sufficient locks > to prevent addition of new partitions while the insertion is > in progress. That will be expensive in itself, and it will > turn ATTACH PARTITION into a performance disaster. Yes, that would require index locks. -- 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.