-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Close connection to base DB after cleanup #5
Close connection to base DB after cleanup #5
Conversation
Interesting, thank you for reporting the issue and for suggesting a fix. Can you explain any more about how you hit the problem and how it manifests? Any suggested way for me to try to reproduce the issue? Running multiple quick tests in parallel is the expected use case of this library and I haven't seen this problem myself. I'll have time later in the week to look into this further and I'll use this PR as a starting point. Thank you again for writing in. |
When running multiple quick tests in parallel it's possible to get a connection failure due to too many clients connected.
bdeb9d9
to
7923c6f
Compare
Hi, I pushed another change to the tests and docker compose. This issues only shows up when the number of parallel tests can potentially be higher than the max connections to the base DB. I updated the docker compose to set max-connections to 100, and the parallel tests to run 50 tests in parallel. Running without this change you should see tests failing due to too many connections. In our code base we use Ginkgo for writing and running tests. After we switched to pgtestdb we noticed that running our ~200 DB related tests in parallel would hit our connection limit (100), but not when running in serial which led me to look at the cleanup code. |
@ebabani hi, thanks for your patience. I've fixed the implementation of Now, when you call `pgtestdb.New()` or `pgtestdb.Custom()`, pgtestdb connects, ensures the template exists, creates the instance db, then cleans everything up like before, but only uses a single connection to the server at any point in time.
Thanks again for reporting this bug. In my testing, re-connecting to the database adds some slight overhead per test, but it's fundamentally more correct, and the database connection time should be dominated by the time taken during each test so overall this is worth the performance impact because it allows you to double the amount of tests you are running at once! I also updated the FAQ to explain the problem, show some example error messages, and provide some ideas for how to work around it. |
^ github actions is having some issues right now but once they're running again, I'll go ahead and merge this. |
Awesome, thanks for the update and the new release. I'll try to update sometimes this week. Thanks for maintaining this project, has been really helpful in parallelizing and speeding up our tests. |
@ebabani of course, you're welcome. Thank you for using it. Please report any further bugs or questions, I'm happy to make improvements. |
When running multiple quick tests in parallel it's possible to get a connection failure due to too many clients connected.