diff options
author | Andres Freund <andres@anarazel.de> | 2020-06-08 16:36:51 -0700 |
---|---|---|
committer | Andres Freund <andres@anarazel.de> | 2020-06-18 14:06:26 -0700 |
commit | 008c119928a3eec4e55560562d872117e08f6df3 (patch) | |
tree | 14ca03f08ac3e49219cbeb593d2d0f0d87e0702b /src/backend/access/transam/xlogutils.c | |
parent | 3b8210da32c4aeca4fe0ba9fdb5a0112b313b7a8 (diff) | |
download | postgresql-008c119928a3eec4e55560562d872117e08f6df3.tar.gz postgresql-008c119928a3eec4e55560562d872117e08f6df3.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/xlogutils.c')
0 files changed, 0 insertions, 0 deletions