Re: [JDBC] Support for JDBC setQueryTimeout, et al. - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [JDBC] Support for JDBC setQueryTimeout, et al.
Date
Msg-id 4CB5B3A50200002500036939@gw.wicourts.gov
Whole thread Raw
In response to Re: [JDBC] Support for JDBC setQueryTimeout, et al.  (Radosław Smogura <rsmogura@softperience.eu>)
Responses Re: [JDBC] Support for JDBC setQueryTimeout, et al.
List pgsql-hackers
Rados*aw Smogura<rsmogura@softperience.eu> wrote:

> I updated patch to latets CVS version, I didn't have time to
> remove some trashes from it.
>
> If something will be wrong with patch, give a feedback.

I skimmed it and agree that it is the right general approach --
using java.util.Timer to trigger the cancel method.  It doesn't
confuse the function of the setQueryTimeout method of the JDBC
driver with the statement_timeout GUC of PostgreSQL, which strike me
as no more or less similar to each other than the brakes on my car
are to a highway guardrail -- both are designed to stop something,
but under different circumstances.

I certainly can't fault you for lack of testing, since about
two-thirds of the patch is testing classes.  I didn't see any need
to include the last two classes (ByteConverter and
InfiniteTimerTask); can you explain why those are in there?

That said, some of the details of the implementation gave me pause
-- there seem to be rather more moving parts and more places to
check things than the overall complexity of the problem would seem
to warrant; however, it's entirely possible that on closer review
I'll find that they were necessary for reasons which escape me on a
quick scan of the code.

If you could add this to the open CommitFest, I'll be glad to review
it (if nobody beats me to it):

https://commitfest.postgresql.org/action/commitfest_view/open

-Kevin

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Path question
Next
From: Bruce Momjian
Date:
Subject: Why do we have a database specification in .pgpass?