hi @egrep,
dint get a chance to look into this yet. Will keep you posted.
-Prasad
This issue has been assigned to me. I expect to have something useful to say about it tomorrow.
The ticket number is MB-19659.
Some findings to date:
- the problem does not repro with only 1 node (I tested on my mac)
- the problem does repro with 3 nodes
- the problem does not repro if 3 duplicate indexes are reduced to a single one
- the problem does not repro if the index is specifically chosen in the query using a USE INDEX (i1 USING GSI) clause
I suspect this is some sort of problem with caching plans across multiple nodes. Perhaps things go wrong when we prepare a plan on one query engine, and try to use it on another.
Iām continuing my investigations.
- the problem does not repro if 3 duplicate indexes are reduced to a single one
- the problem does not repro if the index is specifically chosen in the query using a USE INDEX
Not so bad, sounds like āpartial workaroundsā.
But ācaching plans across multiple nodesā error, as you said, still remains.
There is a fix in process for another pair of bugs (MB-18841/MB-19509) that may fix MB-19659.
@johan_larson,
https://issues.couchbase.com/browse/MB-19509 => Fix versions: spock (2017)
https://issues.couchbase.com/browse/MB-18841 => Fix versions: spock (2017)
Sorry, but this is more like āburied with bureaucracy of developmentā, rather then āfix in processā.
Let me be more specific.
There is an actual changelist currently in review for MB-19509 and MB-18841. I had expected it to be available today, but itās still being reviewed. Once it is accepted and submitted, I will verify whether it also fixes MB-19659. If it does, I will argue for back-propagating the fix to the 4.1 line, which would make it available in the next 4.1.X release and in 4.5.1.
If the current changelist is not accepted or does not solve the problem, this is going to take longer because there is likely to be some wrangling about whether the query engine or the Java SDK needs to change its behavior.
