-
Notifications
You must be signed in to change notification settings - Fork 42
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
c14h, yarpnarp: Be robust against postgresql not being available #8
Labels
Comments
After looking at http://godoc.org/database/sql#Open I think it should be enough to just open the connection on the first use. For that, I recommend:
Also, move to http://godoc.org/database/sql#DB.Ping instead of the SELECT 1 query. |
Merovius
added a commit
to Merovius/nnev-website
that referenced
this issue
Feb 20, 2020
I believe we are currently being bitten by nnev#8 quite regularly. This is exacerbated by not checking for an error by tx.Begin() (that's on me, I presume), so we panic on a nil-pointer, instead of getting an error message. Unfortunately, I still can't see a super clear-cut way to check whether an error is caused by this issue and it shouldn't even *be* an issue, as *sql.DB is a connection pool - so it should just handle this transparently, IMO. But at least if we know the error message, we might get a hint on how to handle that correctly.
Merovius
added a commit
to Merovius/nnev-website
that referenced
this issue
Feb 20, 2020
I believe we are currently being bitten by nnev#8 quite regularly. This is exacerbated by not checking for an error by tx.Begin() (that's on me, I presume), so we panic on a nil-pointer, instead of getting an error message. Unfortunately, I still can't see a super clear-cut way to check whether an error is caused by this issue and it shouldn't even *be* an issue, as *sql.DB is a connection pool - so it should just handle this transparently, IMO. But at least if we know the error message, we might get a hint on how to handle that correctly.
Merovius
added a commit
to Merovius/nnev-website
that referenced
this issue
Jun 3, 2022
I believe we are currently being bitten by nnev#8 quite regularly. This is exacerbated by not checking for an error by tx.Begin() (that's on me, I presume), so we panic on a nil-pointer, instead of getting an error message. Unfortunately, I still can't see a super clear-cut way to check whether an error is caused by this issue and it shouldn't even *be* an issue, as *sql.DB is a connection pool - so it should just handle this transparently, IMO. But at least if we know the error message, we might get a hint on how to handle that correctly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
During boot or restarts of postgresql, it might be, that the connection is temporarily unavailable. We should a) open connections on-demand (only open it, when we try to use it the first time) and b) retry a limited number of times (e.g. exponential backoff), when an error occured due to it closing unexpectedly. database/sql apparently doesn't expose a special error for that, so we have to investigate whether we can catch that in other ways (e.g. if it passes through an error about reading/writing to a closed socket) or need to do a catch-all, on error reopen connection thing.
This is the same issue as nnev/yarpnarp#5 and should be resolved in the same way.
The text was updated successfully, but these errors were encountered: