Re: [JDBC] Support for JDBC setQueryTimeout, et al.
От | Kevin Grittner |
---|---|
Тема | Re: [JDBC] Support for JDBC setQueryTimeout, et al. |
Дата | |
Msg-id | 4CB4454C0200002500036878@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: [JDBC] Support for JDBC setQueryTimeout, et al. (David Fetter <david@fetter.org>) |
Список | pgsql-hackers |
David Fetter <david@fetter.org> wrote: > Let's imagine you have a connection pooler with two clients, > A and B. I'm with you so far. > A calls setQueryTimeout, then starts a query, which terminates in > time, but dies before handling it. Here you lost me. I don't know what that means. > B connects to the pool, gets A's connection, and finds a > statement_timeout that's not the default Why? I would consider the JDBC QueryTimeout property to be orthogonal to the server's statement_timeout GUC. Perhaps that's why we're seeing things so differently. > even though only A's single query was supposed to have that > statement_timeout. This is not a situation that can be resolved > without being able to set a timer *on the server side*. That will be true if we conflate these two things. I don't think we should. http://download.oracle.com/javase/6/docs/api/java/sql/Statement.html#setQueryTimeout%28int%29 This time limit should apply to the overall time allowed in the driver for the execute, executeQuery and executeUpdate of the Java Statement object. It should not be trying to pick apart individual SQL statements within the execute request, and it should not affect any other statement on the connection. I think both patches are making this harder than it needs to be. -Kevin
В списке pgsql-hackers по дате отправления: