On Sat, 6 Apr 2002, Bruce Momjian wrote:
What's wrong with simply issueing set query_timeout
command just before every query ?
You could do that, but we also imagine cases where people would want to
set a timeout for each query in an entire session.
One approach might be for the
On Thu, 4 Apr 2002, Bruce Momjian wrote:
It that acceptable to the JDBC folks? It requires two SET timeout = 0
statements, one after the statement in the transaction, and another
after the transaction COMMIT WORK.
That's fine, though probably about as much work as just implementing the
On Tue, 2 Apr 2002, Barry Lind wrote:
Since both the JDBC and ODBC specs have essentially the same symantics
for this, I would hope this is done in the backend instead of both
interfaces.
The current plan seems to be to make changes in the backend and the JDBC
interface, the bulk of the
On Mon, 1 Apr 2002, Tom Lane wrote:
On the other hand, we do not have anything in the backend now that
applies to just one statement and then automatically resets afterwards;
and I'm not eager to add a parameter with that behavior just for JDBC's
convenience. It seems like it'd be a big
On Tue, 2 Apr 2002, Bruce Momjian wrote:
BEGIN WORK;
query;
SET statement_timeout = 4;
query;
SET statement_timeout = 0;
query;
COMMIT;
SET statement_timeout = 0;
Basically, it does the reset twice, once assuming the transaction
doesn't
On Sat, 30 Mar 2002, Tom Lane wrote:
Au contraire, it is not assuming anything. It is sending off a cancel
request and then waiting to see what happens. Maybe the query will be
Okay, I see now: when processCancelRequest() is called, a return of 127 is
sent. That would indeed work;
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
On Mon, 1 Apr 2002, Jan Wieck wrote:
Why don't we use two separate GUC variables and leave the
BEGIN syntax as is completely?
SET transaction_timeout = m;
SET statement_timeout = n;
What's a GUC variable? Would this apply to all subsequent statements? I
think
On Sat, 30 Mar 2002, Bruce Momjian wrote:
There is clearly interest from all interfaces. This item has been
requested quite often, usually related to client apps or web apps.
I definitely agree that implementing it in the backend would be the best
plan, if it's feasible. I just can't figure
On Sat, 30 Mar 2002, Tom Lane wrote:
Why would this be any different from a cancel-signal-instigated abort?
You'd be reporting elog(ERROR) in any case.
If I understand the code correctly, in the case of a cancel signal, the
driver sends the signal and then assumes that the backend has
On Sat, 30 Mar 2002, Tom Lane wrote:
Au contraire, it is not assuming anything. It is sending off a cancel
request and then waiting to see what happens. Maybe the query will be
canceled, or maybe it will complete normally, or maybe it will fail
because of some error unrelated to the cancel
I have been talking with Bruce Momjian about implementing query
timeouts in the JDBC driver. As things stand, you can call
setQueryTimeout() or getQueryTimeout(), but a slow query will never
actually timeout, even if a timeout is set. The result of a timeout
should be a SQLException.
Bruce feels
On Wed, 13 Mar 2002, Bruce Momjian wrote:
You bet, but it would be done in the backend, not in jdbc. Is that OK?
Theoretically this is okay. I am more comfortable in Java than in C and I
hadn't looked at the backend code at all, but I'll take a peek and see if
it looks like something I'd feel
13 matches
Mail list logo
