Re: Unexpected behavior after OOM errors

>
>
> Hi Michael,

The patch looks correct to me. Deleting the hash slot before raising the
error is exactly the right cleanup, and MCXT_ALLOC_NO_OOM is the cleanest
way to get there.

On the different symptom you see on HEAD (FATAL: releasing ref with pending
data vs. the Assert I got on 17.10): I think this is just a matter of
what's in the hash at exit time. The FATAL fires when the iterator hits a
valid entry_ref with unflushed pending stats before it reaches the poisoned
slot; the Assert fires if it reaches the NULL slot first. My repro sequence
(INSERT committed, then UPDATE aborted) likely leaves no pending stats, so
the NULL slot is always hit first. Anyway, it's the same root cause.

Regarding found && !cache_entry->entry_ref being dead code, I agree.

Thanks for picking this up so quickly!

Alexey