> The obvious fix seems to be limiting the loop explicitly:
That seems to work. The original test finishes normally with it. When I tried to insert more than 0x7ffffff values, the process quickly allocated so much memory that the OS started to page very busily, so after 10-15 minutes of waiting I interrupted that. I then tried to use the # operator, which gave me a negative number: -2147483615. Then I scanned the table in a loop looking for the max key value, and I found it was 2147483681. This is the unsigned 32-bit interpretation of the same binary value. Given this, I suspect that # uses a signed 32-bit integer internally, so if I had much more RAM, I would probably make that overflow even more, into a small positive number.
> If possible, could you report the initial value of '*pna' and the final value of 'optimal' in the last 10 calls to 'computesizes', with your original test?