On Tue, Oct 25, 2022 at 02:25:20PM -0400, Taylor Blau wrote: > Since they were added in c528e17966 (pack-bitmap: write multi-pack > bitmaps, 2021-08-31), the routine to remove MIDXs removed the > multi-pack-index file itself before removing its associated .bitmap and > .rev file(s), if any. > > This creates a window where a MIDX's .bitmap file exists without its > corresponding MIDX. If a reader tries to load a MIDX bitmap during that > time, they will get a warning, and the MIDX bitmap code will gracefully > degrade. > > Remove this window entirely by removing the MIDX last, and removing its > auxiliary files first. We remove that window, but don't we create a new one where a reader may see the midx but not the bitmap? That won't generate a warning (it just looks like a midx that never had a bitmap generated), but it will cause the reader to follow the slow, non-bitmap path. Ideally this would just be atomic, but short of stuffing the metadata into the same file, we can't do that. But the replacement of the midx file itself is atomic, and I'd think everything would (or should at least) follow from there. I.e., why are we reading the midx bitmap without having opened the midx file? Ideally we'd be holding a descriptor for it. -Peff
