Loading...

XML

Word

Printable

JSON

Backwards Compatibility:
Fully Compatible
Operating System:
ALL
Backport Requested:

v4.0
Steps To Reproduce:

Hide

1) disable replication on secondaries
2) run dropDatabase command with writeConcern:
{w:'majority', wtimeout:1}
3) dropDatabase hangs (forever?) instead of raising a wtimeout error

Show
1) disable replication on secondaries 2) run dropDatabase command with writeConcern: {w:'majority', wtimeout:1} 3) dropDatabase hangs (forever?) instead of raising a wtimeout error
Sprint:
Storage NYC 2018-05-21, Storage NYC 2018-06-04
Linked BF Score:
0
Confidence Status:
None

It looks like the dropDatabase command ignores write concern wtimeout on 3.7 replica sets. Is this intentional?

is depended on by

TOOLS-2035 mongofiles_write_concern_mongos.js fails on server unstable

is related to

SERVER-34922 mongofiles sharded cluster write concern test regression in MongoDB 3.7

SERVER-47194 dropDatabase command does not honor wtimeout on v3.6

related to

SERVER-33317 3.7 sharded clusters ignore create command write concern

SERVER-40712 Clarify the behaviour of `db.dropDatabase` and the `dropDatabase` command

SERVER-46668 createIndexes command does not honor wtimeout when replication is disabled on v4.5.0-24-gb801dec

SERVER-53254 increase writeConcern timeout for dropDatabase in tests

(2 related to)

Participants:: Eric Milkie, Esha Maharishi, Githook User, Louis Williams, Shane Harvey