[SERVER-36224] Oplog entries for updates to system.views do not have UUIDs Created: 20/Jul/18  Updated: 29/Oct/23  Resolved: 27/Aug/18

Status: Closed
Project: Core Server
Component/s: Querying, Replication
Affects Version/s: None
Fix Version/s: 4.1.3

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Justin Seyster
Resolution: Fixed Votes: 0
Labels: read-only-views
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0
Sprint: Query 2018-08-27, Query 2018-09-10
Participants:
Linked BF Score: 64

 Description   

I'm not sure what the impact of this could be, but we should be logging the UUID of the collection here: https://github.com/mongodb/mongo/blob/dd803eee22212313c7808ad4de62de51f1fa56f7/src/mongo/db/views/durable_view_catalog.cpp#L152-L160



 Comments   
Comment by William Schultz (Inactive) [ 10/May/19 ]

justin.seyster Was there any reason this change was not backported to 4.0? Unless you have objections, I am going to request a 4.0 backport, since this issue appeared in a BF on the 4.0 branch (BF-12916).

Comment by Githook User [ 27/Aug/18 ]

Author:

{'name': 'Justin Seyster', 'email': 'justin.seyster@mongodb.com', 'username': 'jseyster'}

Message: SERVER-36224 Refactor Collection::updateDocument args

Previously, Collection::updateDocument expected to get a namespace and
UUID from its OplogEntryUpdateArgs, but that is not necessary, because
the collection already knows its own namespace and UUID. This caused a
problem in DurableViewCatalogImpl::upsert(), which did not set the
UUID value in the args, leading to oplog entries without their UUID
value.
Branch: master
https://github.com/mongodb/mongo/commit/b93c2dcc30de6f33f871ff2b8df88ac5afafbbc1

Comment by Judah Schvimer [ 27/Jul/18 ]

This causes an invariant failure during secondary oplog application for updates to system.views that don't have a UUID. As part of this ticket, please add an invariant somewhere that all CRUD oplog entries have a UUID on 4.0 and beyond.

Comment by Andy Schwerin [ 23/Jul/18 ]

Since system.views isn't sharded, I think you'd only have trouble if system.views got dropped and recreated during an initial sync or refetch-based rollback. I suspect that's hard for a user to cause.

Comment by Kyle Suarez [ 23/Jul/18 ]

Okay, throwing this into the Query Team Needs Triage queue. judah.schvimer, we don't know if this omission has any impact though, right? That would help in determining when we're going to schedule this, if at all.

Comment by Judah Schvimer [ 23/Jul/18 ]

yes, when we update a document in the 'system.views' collection, we don't log the UUID of 'system.views'.

Comment by Kyle Suarez [ 23/Jul/18 ]

If I'm reading this correctly, this code is on the view update path (i.e. collMod on a view). Views don't have UUIDs. judah.schvimer, when you say "logging the UUID of the collection", do you mean the UUID of the system.views collection?

Generated at Thu Feb 08 04:42:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.