There's a bug in fast-delete address-deleted cells: if __rec_page_deleted determines the page delete is globally visible, the page is entered into the reconciliation tracking system and the WT_REF.addr field is cleared. If, after that's done, reconciliation returns (on error, or because an update was found that isn't committed and so page eviction isn't possible), the entry in the tracking system will be discarded and because setting WT_REF.addr to NULL causes the page to never be considered again, the page will leak.

Ideally, we'd quit setting WT_REF.addr to NULL and simply look up the block in the tracking system: if it's there, it's been deleted, if it's not there, it should be deleted.

However, there's a note in __rec_page_deleted that's a problem:

* If no such transactions exist, we can discard the leaf page to the 
* block manager, and no cell needs to be written at all.  We set the 
* WT_REF.addr field to NULL for a few reasons: (1) we can avoid doing 
* the free on the next reconciliation (that's only performance, as the 
* underlying tracking routines won't free the same block twice), (2) 
* our caller knows a WT_REF.addr of NULL means we skip the cell when 
* writing the page, and (3) the cache read routine knows a WT_REF.addr 
* of NULL means the underlying page is gone and it has to instantiate 
* a new page.  Note WT-2 and WT-3 are safe: the WT_REF.addr field is never 
* reset once cleared, so it's safe to test it outside of the WT_REF 
* structure lock. 

The problem is going to be the read routine, it's checking WT_REF.addr for a NULL reference, and there's no way we can let the read routine look into the reconciliation tracking information.