Fix issue 2587

[ray6080]

This fixes issue #2587. Also added the case to our test suite.

Also, we should refactor WALPageIdxAndFrame to be able to unpin and unlock itself when it is out of scope later.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (7c19009) 93.20% compared to head (211a48d) 93.25%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2592      +/-   ##
==========================================
+ Coverage   93.20%   93.25%   +0.04%     
==========================================
  Files        1027     1027              
  Lines       38631    38633       +2     
==========================================
+ Hits        36007    36028      +21     
+ Misses       2624     2605      -19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[benjaminwinger]

Also, we should refactor WALPageIdxAndFrame to be able to unpin and unlock itself when it is out of scope later.

I'd tried adding that when implementing #2516. Note that with MSVC you get hangs if you unlock multiple times, so we need to make sure the destructor is called exactly once by making it a move-only type.

But I think I ended up reverting the change (except the one line re-added here apparently) since it occurred to me that it might be better to use DBFileUtils::updatePage.
On the other hand, that might need a variant that includes the elemPosInPage or some other form of additional information to take the place of WALPageIdxPosInPageAndFrame (maybe by just wrapping it with an additional function, similarly to how WALPageIdxPosInPageAndFrame is currently only constructed within the code that needs it and we otherwise just use createWALVersionIfNecessaryAndPinPage).

I think there are also some redundant calls to insertNewPage, as createWALVersionIfNecessaryAndPinPage seems to handle that itself.