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
Orphan database connections resulting in inability to connect to databases #5567
Comments
Same issue here. But from my side, I didn't see the log you provided. |
@tsschubert This is a complex problem.
Only place I think the connections can be closed if user logout. Did you try logout? |
I have verified the issue, MAX_SESSION_IDLE_TIME is not being honoured. |
Same here, |
I have this issue on latest snapshot (6.18+) |
This is working fine. Verified with Docker & centos-7 in server mode. |
We are testing this bugfix on v6.20 for more than a week now and are still experiencing this issue. The connection icon on the Servers just spins forever: We cannot find any related logs on pgadmin. It's fine again after performing a deployment restart. These are our pgadmin settings:
Please reopen this issue. |
@MalteKud |
Even at peak times, there will be no more than 10 users connecting to a server. I will try to reproduce this issue in the next few days to check browser console logs and post my findings here. We are deploying the pgadmin Docker image to EKS with Terraform. This is our Terraform Kubernetes deployment resource: |
We managed to reproduce the issue. Please find the corresponding console logs: FYI @MalteKud |
We're experiencing similar issue since upgrading to version 6 (6.17 in our case, we were very stable on 5.7). We authenticate via SSO, then randomly the login either spins after that trying to connect or just spins endlessly on the Servers connection icon. The pod appears to not be under any resource issue at the time. |
warning: stuck on connecting to the DB happens still with 6.21, you should reopen this ticket @akshay-joshi @MalteKud @ilichivan ... |
Could you please provide logs when this issue occurs? |
Kubernetes config shows very small resources are allocated to pgAdmin -
|
I have to wait until it gets stucked again the logs you want are the output of "kubectl logs 'NAME_OF_POD' ..." or something else? |
@yogeshmahajan-1903 we have a similar issue again today on 6.17 (I believe my college Aruna has been in touch with you on this already - Aruna is going to email you the log output from the time we had the issue) - Issue is stuck on spinning circle when trying to list the databases and eventually times out with 'Unknown Error'. │ resources: ││ limits: ││ cpu: "4" ││ memory: 50Gi ││ requests: ││ cpu: "2" ││ memory: 50Gi |
Yes. |
Could you please provide screenshot of the error & error logs? |
@yogeshmahajan-1903 Please find the attached screen shots as required. There are lot of 503 error during this time, please find below error messages <public_ip> - - [14/Apr/2023:11:51:44 +0000] "GET /sqleditor/status/4397343 HTTP/1.1" 500 103 "https:///sqleditor/panel/4397343?is_query_tool=true&sgid=96&sid=307&did=dbid&database_name=" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0" |
Hi, happend today again with 6.21, find full logs of POD after long time
|
I have the same issue like @nigzak today. |
FYI: I have installed PgAdmin 7.1 - the "endless loading bar" issue did not happen again yet for around 2 weeks |
I have pgadmin 6.15 deployed in kubernetes. Users can authenticate to databases using the pgpass file and a server that is preconfigured on startup. A user can either leave the page, or close their browser, but the underlying connection to the database is kept intact indefinitely. At a certain point (undetermined), there are too many connections open to databases that pgadmin is unable to connect to any database. The connection spins and the logs show:
The lock is never achieved and eventually the connection request will timeout.
I have the following settings in place for pgadmin:
In this case, it does not appear that
MAX_SESSION_IDLE_TIME
is being honored.This behavior has been seen in all PgAdmin versions we've run (6.12+).
The text was updated successfully, but these errors were encountered: