tests: fail tests which write too much data #9537
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jcsp
force-pushed
the
jcsp/test-fail-on-too-much-data
branch
from
23a37c3 to
7635345
Compare
7282 tests run: 6749 passed, 169 failed, 364 skipped (full report)Failures on Postgres 17
Failures on Postgres 16
Failures on Postgres 15
Failures on Postgres 14
Test coverage report is not availableThe comment gets automatically updated with the latest test results
cc14a84 at 2025-01-10T18:07:25.706Z :recycle: |
jcsp
force-pushed
the
jcsp/test-fail-on-too-much-data
branch
3 times, most recently
from
afd4404 to
7ef9d33
Compare
jcsp
force-pushed
the
jcsp/test-fail-on-too-much-data
branch
from
7ef9d33 to
434b0aa
Compare
This was referenced Jan 10, 2025
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jan 10, 2025
## Problem I noticed in #9537 that tests which work with compat snapshots were writing several hundred MB of data, which isn't really necessary. Also, the snapshots are large but don't have the proper variety of storage format features, e.g. they could just have L0 deltas. ## Summary of changes - Use smaller scale factor and runtime to generate less data - Configure a small layer size and use force image layer generation so that our output contains L1 deltas and image layers, and has a decent number of entries in the layer map
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jan 10, 2025
## Problem This test writes ~5GB of data. It is not suitable to run in parallel with all the other small tests in test_runner/regress. via #9537 ## Summary of changes - Move test_parallel_copy into the performance directory, so that it does not run in parallel with other tests
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jan 10, 2025
## Problem These two tests came up in #9537 as doing multi-gigabyte I/O, and from inspection of the tests it doesn't seem like they need that to fulfil their purpose. ## Summary of changes - In test_local_file_cache_unlink, run fewer background threads with a smaller number of rows. These background threads AFAICT exist to make sure some I/O is going on while we unlink the LFC directory, but 5 threads should be enough for "some". - In test_lfc_resize, tweak the test to validate that the cache size is larger than the final size before resizing it, so that we're sure we're writing enough data to really be doing something. Then decrease the pgbench scale.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
We see tests fail on service startup in a way that suggests some other rogue tests might be loading the test machines too heavily.
Summary of changes
Checklist before requesting a review
Checklist before merging