unit-PageTest regression due to commit 58445038

[Aleaxander]

Hi @Tryneus,

JFYI, my test framework caught a unit-PageTest regression due to commit 5844503(" moving transaction throttling limit changing logic into the throttler").

I'm sorry for the noisy if you are already aware of this.

Here is the test log:

Running 1 of 178 tests (tasks: 1, repeats: 1, output dir: test_results.mA1nU, build: release, filter: unit-PageTest)
Run  unit-PageTest (1)
Note: Google Test filter = PageTest.*
[==========] Running 15 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 15 tests from PageTest
[ RUN      ] PageTest.Control
[       OK ] PageTest.Control (3 ms)
[ RUN      ] PageTest.CreateDestroy
[       OK ] PageTest.CreateDestroy (1 ms)
[ RUN      ] PageTest.OneTxn
[       OK ] PageTest.OneTxn (2 ms)
[ RUN      ] PageTest.TwoIndependentTxn
[       OK ] PageTest.TwoIndependentTxn (1 ms)
[ RUN      ] PageTest.TwoIndependentTxnSwitch
[       OK ] PageTest.TwoIndependentTxnSwitch (2 ms)
[ RUN      ] PageTest.TwoSequentialTxnSwitch
[       OK ] PageTest.TwoSequentialTxnSwitch (1 ms)
[ RUN      ] PageTest.OneWriteAcq
[       OK ] PageTest.OneWriteAcq (3 ms)
[ RUN      ] PageTest.OneWriteAcqOneReadAcq
[       OK ] PageTest.OneWriteAcqOneReadAcq (2 ms)
[ RUN      ] PageTest.OneWriteAcqWait
[       OK ] PageTest.OneWriteAcqWait (2 ms)
[ RUN      ] PageTest.ReadAfterWrite
[       OK ] PageTest.ReadAfterWrite (2 ms)
[ RUN      ] PageTest.WriteWaitForFlush
[       OK ] PageTest.WriteWaitForFlush (2 ms)
[ RUN      ] PageTest.BiggerTest
[       OK ] PageTest.BiggerTest (4 ms)
[ RUN      ] PageTest.BiggerTestTightMemory
Time unit-PageTest (1)

[Tryneus]

Thanks, @Aleaxander! Looking into this.

[Tryneus]

For the record, it appears that the unittests don't work with a transaction limit of 1, but I'm not sure if that holds for the server.

[Tryneus]

Just ran some tests on the server with --cache-size 0, and it appears this doesn't cause hangs in normal operation. I ran an insert workload across multiple clients while throwing in some sindex post-construction. Performance dipped fairly quickly (because with no cache, the throttler only allows one write through at a time), but no failures or hangs. The only slightly perturbing behavior was that sindex creation didn't finish until I stopped the write workload for a couple seconds, but that isn't exactly unexpected.

The PageTest unittests appear to make some assumptions about cache throttling that are no longer true (assumptions that the rest of the code doesn't make), so I think the test needs to be updated.

[AtnNn]

@Tryneus thanks for testing this. I will ignore that test for now.

[anatol]

Confirm that these 3 tests cause hang: PageTest.BiggerTestTightMemory,PageTest.BiggerTestSuperTightMemory,PageTest.BiggerTestNoMemory

I had to disable them in Linux Arch rethinkdb package.

[srh]

The PageTest assumes that its write transactions are not going to get throttled. I might add a flag to the page_txn_t constructor that lets it force-acquire the throttling semaphore (which would either (a) also cause preceding transactions to force-acquire the throttling semaphore, or (b) cause preceding transactions on the same cache_conn_t to force-acquire the throttling semaphore). Or, I might decouple the throttler from the page_cache_t a bit.

[srh]

Fixed in sam_2187 (branched off v1.12.x), awaiting code review 1384. I merely made the minimum unwritten changes limit be parameterizable.

[Aleaxander]

@srh, yes, it does work.

[srh]

In v1.12.x as of 83b85f0.