Deletion of ranges that are unique - like databases, object stores, and indexes - don't need to happen right away because those key ranges will never be used again.

Instead of requiring that we atomically delete those ranges, we can instead mark that range as 'doomed', and then have a task that gradually goes through all 'doomed' ranges and deletes them. These deletes can be batches so that they don't cause the WriteBatch to OOM the browser.

The down side is that this means that quota will not be freed up right away.

Note - this feature could be supported by the LevelDB Scopes work, depending on how it stores the undo logs.
 

Deletion of ranges that are unique - like databases, object stores, and indexes - don't need to happen right away because those key ranges will never be used again.

Instead of requiring that we atomically delete those ranges, we can instead mark that range as 'doomed', and then have a task that gradually goes through all 'doomed' ranges and deletes them. These deletes can be batches so that they don't cause the WriteBatch to OOM the browser.


The down side is that this means that quota will not be freed up right away.

Unknowns:
* This feature could be supported by the LevelDB Scopes work, depending on how it stores the undo logs.
* How complex the 'tuning' needs to be so we don't end up with a ton of undeleted data for a while.
* Do we need 'push back' of things doing deferred deletion if it's possible to accidentally fill up the disk by deleting too quickly.
 

Deletion of ranges that are unique - like databases, object stores, and indexes - don't need to happen right away because those key ranges will never be used again.

Instead of requiring that we atomically delete those ranges, we can instead mark that range as 'doomed', and then have a task that gradually goes through all 'doomed' ranges and deletes them. These deletes can be batches so that they don't cause the WriteBatch to OOM the browser.


The down side is that this means that quota will not be freed up right away.

Unknowns:
* This feature could be supported by the LevelDB Scopes work, depending on how it stores the undo logs.
* How complex the 'tuning' needs to be so we don't end up with a ton of undeleted data for a while.
* Do we need 'push back' of things doing deferred deletion if it's possible to accidentally fill up the disk by deleting too quickly.

Affected parties:
* Websites with large IndexedDB databases > 2gb. One example is Gmail.