-
Notifications
You must be signed in to change notification settings - Fork 180
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
read_timeout default #83
Comments
this error is thrown if no new messages are read from vertica for 10 minutes. as far as im aware, there isn't a heartbeat mechanism that we can use to check if the query is still being process (i could easily be missing something though). im open to increasing the default value if you think that makes more sense. |
In my case, I had a COPY statement taking 30 minutes to run and it would kick out for a Connection Timeout. When I increased this number, it worked fine. I was just not sure if this is the normal behavior in this circumstance, and if it is, then I just think more visibility needs to be around it because it's basically a max wait time for a query to return. Incidentally, my query on the server continued to run for 20 more minutes before rolling back. I really only figured it out because I allow retry on my loads if I get a connection class error and this caused a very unfortunate snowball effect. ;-) |
And while I'm thinking about this, I do like the idea of giving some max timeout before getting control back... What would be nice is if a query is executing, you could wait x seconds for a return or get control back and then go back into a wait state much like we do with sockets and queue waits. I just don't want to lose my query if it takes too long. |
Got same issue on COPY statement! +1 |
Another extreme case: if I set read_timeout = 0.000000001, what will happen? Most operations will be halted? @alexjikim |
This issue is out-of-date as 'read_timeout' option is removed. @mm57950 I think the answer for your question is yes. |
When the read_timeout default is set to 10 minutes and I have a long running query, I get a connection timeout error. Changing this to 60 minutes fixed my problem.
Does this parameter always cause a connection timeout for queries that exceed the timeout? (As in, is this the intent of this parameter, or is there some other side-effect going on, like a heartbeat not working, etc) If so, 10 minutes default seems pretty short and should be called out in the docs somewhere.
The text was updated successfully, but these errors were encountered: