Skip to content
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

Closed
mverrilli opened this issue Nov 9, 2015 · 6 comments
Closed

read_timeout default #83

mverrilli opened this issue Nov 9, 2015 · 6 comments

Comments

@mverrilli
Copy link

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.

@alexjikim
Copy link
Contributor

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.

@mverrilli
Copy link
Author

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. ;-)

@mverrilli
Copy link
Author

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.

@juise
Copy link

juise commented Jul 31, 2017

Got same issue on COPY statement!

+1

@mm57950
Copy link

mm57950 commented Apr 9, 2019

Another extreme case: if I set read_timeout = 0.000000001, what will happen? Most operations will be halted? @alexjikim

@sitingren
Copy link
Member

This issue is out-of-date as 'read_timeout' option is removed.

@mm57950 I think the answer for your question is yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants