Thread: Re: [JDBC] Support for JDBC setQueryTimeout, et al.

Re: [JDBC] Support for JDBC setQueryTimeout, et al.

From
"Kevin Grittner"
Date:
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


Re: [JDBC] Support for JDBC setQueryTimeout, et al.

From
Bruce Momjian
Date:
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. +

Re: [JDBC] Support for JDBC setQueryTimeout, et al.

From
Tom Lane
Date:
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

Re: [JDBC] Support for JDBC setQueryTimeout, et al.

From
Bruce Momjian
Date:
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. +

Re: [JDBC] Support for JDBC setQueryTimeout, et al.

From
"Kevin Grittner"
Date:
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

Re: [JDBC] Support for JDBC setQueryTimeout, et al.

From
Bruce Momjian
Date:
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. +