Summary

timestamp_abort (and our other _abort tests) doesn't do any more work on the database after it recovers it and verifies it after crash. The test should do more work on the database in order to uncover any potential issues that might happen only after recovering from an unclean shutdown, which, for example, seems to be the case of HELP-41498.

Acceptance criteria

The test program should take an additional command-line argument that specifies the number of iterations that the test should run, where an iteration means running a workload, crashing, and recovering. For example, running three iterations means that we would crash the database three times, and we would run a workload on a formerly crashed database twice.

Possible approach

The work/crash/recovery/verify part of the main() function should be in a for loop. For simplicity, we should modify the initial keys and timestamps so that there is no overlap between iterations. (Having overlap between iterations might be an interesting extension later.)