Jessica, My reading of the JDBC spec would indicate that this is a statement level property (aka query level) since the method to enable this is on the Statement object and is named setQueryTimeout(). There is nothing I can find that would indicate that this would apply to the transaction in my reading of the jdbc spec.
thanks, --Barry Jessica Perry Hekman wrote: > On Mon, 1 Apr 2002, Bruce Momjian wrote: > > >>I don't know which people want, and maybe this is why we need both GUC >>and BEGIN WORK timeouts. I don't remember this distinction in previous >>discussions but it may be significant. Of course, the GUC could behave >>at a transaction level as well. It will be tricky to manage multiple >>alarms in a single process, but it can be done by creating an alarm >>queue. > > > I think we should do just BEGIN WORK (transaction-level) timeouts; that is > all that the JDBC spec asks for. Does that sound good to people? > > So the work that would need to be done is asking the driver to request the > timeout via "BEGIN WORK TIMEOUT 5"; getting the backend to parse that > request and set the alarm on each query in that transaction; getting the > backend to send a cancel request if the alarm goes off. I am right now in > the process of finding the place where BEGIN-level queries are parsed. Any > pointers to the right files to read would be appreciated. > > j > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org