[SERVER-54410] [SBE] Tailable cursors are broken when SBE is on and legacy reads are enabled Created: 09/Feb/21  Updated: 29/Oct/23  Resolved: 25/Feb/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Bug Priority: Major - P3
Reporter: David Storch Assignee: Nikita Lapkov (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Query Execution 2021-03-08
Participants:

 Description   

As a simple repro, start a mongod with SBE enabled:

./mongod --setParameter featureFlagSBE=true

Then run the following through the shell:

db.getMongo().forceReadMode("legacy");
db.c.drop();
db.createCollection("c", {capped: true, size: 1024});
db.c.insert({a: 1});
db.c.find().tailable();

This query fails spuriously with the following error during the first OP_GET_MORE operation:

MongoDB Enterprise > db.c.find().tailable();
Error: error: {
	"$err" : "OP_GET_MORE operations are not supported on tailable aggregations. Only clients which support the getMore command can be used on tailable aggregations.",
	"code" : 40548
}

The reason is that this check assumes that only aggregate cursors use the "locks internally" lock policy. This is no longer true, since find cursors using the SBE engine also use the "locks internally" lock policy.



 Comments   
Comment by Githook User [ 25/Feb/21 ]

Author:

{'name': 'Nikita Lapkov', 'email': 'nikita.lapkov@mongodb.com', 'username': 'laplab'}

Message: SERVER-54410 Disable SBE for queries from OP_QUERY
Branch: master
https://github.com/mongodb/mongo/commit/94ba01727ac8afc65eff6d318c9116bb14d27ccf

Comment by Anton Korshunov [ 18/Feb/21 ]

david.storch Agreed. Assigning it to the next sprint to implement the fallback logic.

Comment by David Storch [ 09/Feb/21 ]

anton.korshunov, to reduce our test surface area for 5.0, I think it might be wise to keep using the classic execution engine for queries using legacy reads (OP_QUERY/OP_GET_MORE). Modern clients will never use legacy reads, so it shouldn't matter much to users that such read operations continue to use the legacy execution engine as well. The only reason I see to make legacy reads use SBE would be if this is required in order to stop supporting the classic execution engine altogether, which of course would require a bunch of other projects to be completed before OP_QUERY/OP_GET_MORE becomes the gating item.

Generated at Thu Feb 08 05:33:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.