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 i
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 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
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 Mon, 1 Apr 2002, Peter Eisentraut wrote:
> Does it time out only queries or any kind of statement?
Any kind, I believe.
FWIW, I took a look at the recommended JDBC driver for MySQL, hoping for
ideas; it does not implement query timeouts at all. I'll take a look at
mSQL next.
j
---
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
thi
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.
On Mon, 1 Apr 2002, Tom Lane wrote:
> This assumes that the query timeout should apply to each subsequent
> query, individually, until explicitly canceled. If you want a timeout
> that applies to only one query and is then forgotten, then maybe this
> wouldn't be the most convenient definition.
> 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 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 can
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 accept
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
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, 27 Mar 2002, Tom Lane wrote:
> 2. Shouldn't the filter patterns be tightened up considerably? For
> example, I consider it sheer folly that I cannot use the word "c*ncel"
> in a Postgres discussion group without my posting being held up for
> several days.
I was wondering if we could i
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
16 matches
Mail list logo
