-
Notifications
You must be signed in to change notification settings - Fork 247
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document global var / setting idle_timeout
solutions for long-running development processes eg. Next.js
#119
Comments
Hi @karlhorky .. Is this with v1 or v2-beta? Hehe, scratch that, not relevant, I should read closer :) brb... |
Ah ok, I see the issue now. I think this is probably an issue for a lot of libraries using next.js. I'm afraid it might be more confusing if information about the global workaround is added to the Postgres.js documentation - what do you think? |
Yes, on further consideration, I think documenting Option 1 would be misplaced in the docs here. I have asked if they would accept a PR for me to document it in the Next.js docs instead. However, for Option 2, I would see value in having a short readme section on the fact Postgres.js does not automatically close connections, including example usage of the |
Yeah, that would be great! Much welcomed 馃檪 |
Hi @porsager! 馃憢
Since a while now, students at @upleveled have been running into an issue where refreshes of a page (and Fast Refresh) are causing further database connections, and the old connections are not going away. This leads to confusing errors like (also mentioned in #42):
The teardown / cleanup section in the readme with the
prexit
example appears to be helpful, butprocess.exit
is not actually called during the development workflow (multiple page refreshes and Fast Refresh hot reloads when a file is changed).As far as I can tell, there are a couple of different solutions to this:
idle_timeout
that will cause the idle connections to be terminated fairly quickly (eg. after 2 seconds)Would you be open to me creating a section in the readme addressing this problem with option 1 as a recommended solution for development workflows for these long-running apps? With maybe option 2 as an "alternative" solution?
The text was updated successfully, but these errors were encountered: