Info

SERVER-26202 relaxed a lot of index constraints but missed a few. We should re-audit index_catalog_impl.cpp for errors that can be ignored.

Top User Comments

xgen-internal-githook commented on Tue, 5 May 2020 16:04:21 +0000: Author: {'name': 'Ali Mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'} Message: SERVER-32225 Only limit number of text indexes created by user connections (cherry picked from commit 7ce7dc274c7c899855f14ac55b5344b32399598c) Branch: v4.4 https://github.com/mongodb/mongo/commit/73a812bd10647977e7b2ad6f1614ab0cfbe2b007 xgen-internal-githook commented on Tue, 21 Apr 2020 21:36:54 +0000: Author: {'name': 'Ali Mir', 'email': 'ali.mir@mongodb.com', 'username': 'ali-mir'} Message: SERVER-32225 Only limit number of text indexes created by user connections Branch: master https://github.com/mongodb/mongo/commit/7ce7dc274c7c899855f14ac55b5344b32399598c william.schultz commented on Fri, 31 Jan 2020 00:44:44 +0000: If we need to write a repro test when working on the fix for this, I'd be interested to see if we could reproduce some of the original bugs in the initial sync fuzzer. We recently worked on a manual repro for something similar in SERVER-32903, and it seemed a good candidate for a bug that the initial sync fuzzer could catch and deterministically reproduce. I would be interested in the prospect of adding create/drop index operations to the fuzzer grammar as a part of fixing this or related tickets, if it adds sufficient value. siyuan.zhou@10gen.com commented on Fri, 8 Nov 2019 17:08:26 +0000: Right, I think the correctness depends on the fact we cannot change the index name and update another field in the same command. judah.schvimer commented on Fri, 8 Nov 2019 12:34:05 +0000: So siyuan.zhou, am I correct that the safety of the index case is based on the fact that the only "unique index" for indexes is on the name, which is the primary key? The above case for documents only exists when there is a secondary unique index? siyuan.zhou@10gen.com commented on Thu, 7 Nov 2019 22:07:36 +0000: Here's an example of an update modifying more than one field. We cannot just ignore the duplicate key error since there might be other fields modified in the same operation as in the following case (as discussed in CLOUDP-5551: I {_id : 1, a:2} --- Clone Start Optime --- U {_id : 1, b:3} U {_id : 1, a:1, b:1} // This cannot be ignored due to a duplicate key error. U {_id : 1, a:2} I {_id : 2, a:1} --- Clone End Optime --- Reapplying from Clone Start Optime to Clone End Optime. judah.schvimer commented on Thu, 7 Nov 2019 14:50:58 +0000: If the update on unique indexed field fails and rolls back the change of the normal field in the same WT transaction, then we'll lose the change of the normal field when ignoring the error. siyuan.zhou, what do we do here now for normal updates? Is the document guaranteed to be removed in the case you're describing? siyuan.zhou@10gen.com commented on Thu, 7 Nov 2019 05:48:08 +0000: Thanks louis.williams! Since index can be viewed as a document with a unique index on its name in terms of idempotnecy. I was wondering whether a similar case of updating a unique indexed field and another normal field in one update could happen. If the update on unique indexed field fails and rolls back the change of the normal field in the same WT transaction, then we'll lose the change of the normal field when ignoring the error. I don't think a similar case could happen here. The worst case is to change the "expireAfterSeconds" on a wrong index, but the wrong index will be dropped eventually. Thus ignoring the error should be safe. louis.williams commented on Mon, 4 Nov 2019 18:25:55 +0000: siyuan.zhou the only property of an index that may change is the "expireAfterSeconds" with collMod, which is used for TTL indexes, but an index may not change names. siyuan.zhou@10gen.com commented on Thu, 17 Oct 2019 20:50:17 +0000: To my understanding, we only allow create and drop indexes, so there's no way to update a property of an existing index or change its name. louis.williams, is this correct? If so, I think the proposed solution is safe in term of idempotency.

Steps to Reproduce