Thread: Re: [JDBC] Support for JDBC setQueryTimeout, et al.
Tom Lane wrote: > I'm all for doing this client-side. Well, that makes a big difference. Unless someone can make a convincing argument for why we should modify the server side to support this, I think we should just focus on this one client-side patch. I'd be happy to give it a closer look, but I may not be able to do so for a few weeks, and won't complain if someone beats me to it. -Kevin
Kevin Grittner wrote: > Tom Lane wrote: > > > I'm all for doing this client-side. > > Well, that makes a big difference. Unless someone can make a > convincing argument for why we should modify the server side to > support this, I think we should just focus on this one client-side > patch. > > I'd be happy to give it a closer look, but I may not be able to do so > for a few weeks, and won't complain if someone beats me to it. Uh, why would we do this client-side rather than server-side? If we do it server-side, all interfaces get it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
>> Tom Lane wrote:
>>> I'm all for doing this client-side.
> Uh, why would we do this client-side rather than server-side? If we do
> it server-side, all interfaces get it.
1. The API that's being implemented is JDBC-specific.
2. Even if you want to argue that it would be generally useful to have
such a feature, it would certainly require additional client-side
programming to make each client interface make use of it.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > >> Tom Lane wrote: > >>> I'm all for doing this client-side. > > > Uh, why would we do this client-side rather than server-side? If we do > > it server-side, all interfaces get it. > > 1. The API that's being implemented is JDBC-specific. > > 2. Even if you want to argue that it would be generally useful to have > such a feature, it would certainly require additional client-side > programming to make each client interface make use of it. Wouldn't it be simpler to code this in the server and have the client use that facility, rather than have the each client implement it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> wrote: > why would we do this client-side rather than server-side? Because the timeout is supposed to be a limit on the time allowed for specific Java methods to complete, which might be running a large number of SQL statements within one invocation, and which may include significant network latency. It's a lot of work to get "pretty close" on the server side, and you can never really implement exactly what the JDBC API is requesting. What if you have an app which can draw data from any of a number of remote databases, and you want to use this limit so if one becomes unavailable for some reason you can re-run the request on another within a reasonable time? The network connection goes down after you submit your request, you've got a period of minutes or hours until TCP gives up, and the user expects a response within a few seconds... If you implement something with server-side semantics, there's nothing to prevent an application which is PostgreSQL-aware from accessing it through JDBC, of course. statement_timeout and other GUCs can be set locally to your heart's content. -Kevin
Kevin Grittner wrote: > Bruce Momjian <bruce@momjian.us> wrote: > > > why would we do this client-side rather than server-side? > > Because the timeout is supposed to be a limit on the time allowed > for specific Java methods to complete, which might be running a > large number of SQL statements within one invocation, and which may > include significant network latency. It's a lot of work to get > "pretty close" on the server side, and you can never really > implement exactly what the JDBC API is requesting. > > What if you have an app which can draw data from any of a number of > remote databases, and you want to use this limit so if one becomes > unavailable for some reason you can re-run the request on another > within a reasonable time? The network connection goes down after > you submit your request, you've got a period of minutes or hours > until TCP gives up, and the user expects a response within a few > seconds... > > If you implement something with server-side semantics, there's > nothing to prevent an application which is PostgreSQL-aware from > accessing it through JDBC, of course. statement_timeout and other > GUCs can be set locally to your heart's content. OK, thanks. Just had to ask. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +