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