[SERVER-59842] Setting wildcard index as multikey can cause prepare conflicts Created: 08/Sep/21 Updated: 11/Nov/21 Resolved: 11/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Samyukta Lanka | Assignee: | Judah Schvimer |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Steps To Reproduce: | 1. Create a wildcard index |
||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 15 | ||||||||||||||||
| Description |
|
We can cause a prepare conflict if we set a wildcard index as multikey as part of a prepared transaction and then try to set it as multikey through a write separate from the transaction. The conflict comes from when we insert keys into the index itself for wildcard indexes (multiMetadataKeys is populated by the wildcard_key_generator). I think that is done in the same wuow as the transaction, which means that it will generate a prepare conflict if we try to write on top of it. I suspect this would be resolved if we did these writes in a side transaction block, like when we set the index as multikey. |
| Comments |
| Comment by Judah Schvimer [ 11/Nov/21 ] |
|
Closing per samy.lanka's suggestion. |
| Comment by Samyukta Lanka [ 09/Sep/21 ] |
|
I'm starting to question whether this is worth fixing. The prepare conflict should resolve once we abort or commit the prepared transaction. If the prepared transaction exists indefinitely, then I think we'll have other issues to deal with. |
| Comment by Samyukta Lanka [ 09/Sep/21 ] |
|
It looks like doing the writes in a side transaction block will cause other issues with transactions. Let's say we try to use the multikey path from the wildcard index to find some documents in the same transaction that set the index as multikey. The side transaction block writes at a timestamp not included in the readTimestamp for the transaction, which means that if we need to access the keys written to the index within the same transaction (like when serving a read), we'll hit an issue due to snapshot isolation. |