[zahariash]

This work was produced with the help of language models.

Fixes #1510.

Copying 990,442 STRING keys into one table with commits at 141,501 rows and then every 250,000 left 5 keys unreachable on 0.22.1: MATCH (n:G {id: $k}) RETURN count(n) returned 0. With commits every 250,000 rows from the start, no key was lost. A smaller load with keys chosen by hash loses 9 of 18 keys on 0.18.0, 0.22.1 and main. There a scan still returns all 600 rows, and a rel COPY fails with Copy exception: Unable to find primary key value long-enough-primary-key-229740. Inserting a lost key again succeeds, which leaves two rows with one primary key, also after a reopen. INT64 keys lose entries too.

Fix. HashIndex::splitSlots buffers new overflow slots in a vector. One checkpoint can grow an index far enough to split a slot created earlier in the same pass, so the chain being read sits in the buffer being appended to. A reallocation left originalSlot on freed memory, whose first bytes hold the slot's fingerprints and get overwritten by the allocator, so entries moved with wrong fingerprints. The buffer is now a std::deque, whose elements stay in place as it grows.

The on-disk format is unchanged. A database built before this fix keeps its lost entries until the table is reloaded, and keeps stale copies of moved entries in the old chains. A growing checkpoint over those finishes on the 0.22.1 release build, with the other keys still found, and fails newSlotId == newSlotIterator.idx() on a runtime-checks build, this fix included.

Tests. SplitOfChainInNewOverflowSlotsKeepsKeysReachable picks keys by hash so that the second of two checkpoints moves 18 of them twice, then looks up all 600 keys after a reopen. On main 9 lookups return 0. That failure depends on what the allocator writes into freed memory and has only been run with glibc. The test runs at the default 4 KiB page only, since its keys are chosen for an index starting at 16 slots. Full ctest: 3358/3358.

Cost. Only checkpoints that grow an index take this path. A single-threaded 400,000-key load with commits at 140,000 and 390,000 rows costs 1,890 more mallocs on 2,236,783, and its instruction count stays within repeat noise (runtime-checks builds).

The issue's separate failure with an 8 GiB buffer_pool_size isn't touched here and needs its own issue.

[sebastianbluhm]

I ran into the same bug independently on a different load and found the same cause: the std::vector buffer in splitSlots. I applied the same deque change to v0.18.1. With a fresh load the build passes with runtime checks on, and all 742,885 keys resolve through the PK index when read with the unpatched 0.18.1 wheel. So I can confirm the fix.