aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/transam/commit_ts.c
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2020-06-08 16:36:51 -0700
committerAndres Freund <andres@anarazel.de>2020-06-18 14:06:27 -0700
commite027219f213111743a51e19e9febface5871af76 (patch)
tree0445f7fa280dfab5238c6fc4aa7a1c8b85e94842 /src/backend/access/transam/commit_ts.c
parent070f49005350131a62399b9b29bff61f8adaefff (diff)
downloadpostgresql-e027219f213111743a51e19e9febface5871af76.tar.gz
postgresql-e027219f213111743a51e19e9febface5871af76.zip
Add basic spinlock tests to regression tests.
As s_lock_test, the already existing test for spinlocks, isn't run in an automated fashion (and doesn't test a normal backend environment), adding tests that are run as part of a normal regression run is a good idea. Particularly in light of several recent and upcoming spinlock related fixes. Currently the new tests are run as part of the pre-existing test_atomic_ops() test. That perhaps can be quibbled about, but for now seems ok. The only operations that s_lock_test tests but the new tests don't are the detection of a stuck spinlock and S_LOCK_FREE (which is otherwise unused, not implemented on all platforms, and will be removed). This currently contains a test for more than INT_MAX spinlocks (only run with --disable-spinlocks), to ensure the recent commit fixing a bug with more than INT_MAX spinlock initializations is correct. That test is somewhat slow, so we might want to disable it after a few days. It might be worth retiring s_lock_test after this. The added coverage of a stuck spinlock probably isn't worth the added complexity? Author: Andres Freund Discussion: https://postgr.es/m/20200606023103.avzrctgv7476xj7i@alap3.anarazel.de
Diffstat (limited to 'src/backend/access/transam/commit_ts.c')
0 files changed, 0 insertions, 0 deletions