[SERVER-38824] Investigate dropped collections coming back into existence Created: 03/Jan/19  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Storage
Affects Version/s: 4.0.5
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Backlog - Storage Engines Team
Resolution: Unresolved Votes: 0
Labels: storage-engines
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to WT-4450 Add testing around timestamping updat... Closed
is related to WT-4477 Add eviction debug mode and extra checks Closed
Assigned Teams:
Storage Engines
Participants:
Case:

 Description   

There are cases where a collection dropped from the _mdb_catalog reappear. The hypothesis is that the following sequence performed by a secondary:

  1. Create collection
  2. Complete a background index on the collection
  3. Drop the collection

can result in the collection reappearing in state 2 when those individual updates are pushed to WT's lookaside table. The common manifestation is that a restart of the mongod process will fail with fatal assertion code 34433 because the _mdb_catalog refers to a table that was dropped from WT.



 Comments   
Comment by Jocelyn del Prado [ 05/Apr/19 ]

Switching this to the backlog fix version and raised the priority of the 2 linked tickets.

Comment by Daniel Gottlieb (Inactive) [ 16/Jan/19 ]

Yep

Comment by Alexander Gorrod [ 15/Jan/19 ]

The two related WiredTiger tickets are being picked up at the moment - once the WT tickets are resolved, we will revisit this, and hopefully have a path forward. Does that make sense daniel.gottlieb?

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