| From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Jessica Perry Hekman" <jphekman(at)dynamicdiagrams(dot)com>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: timeout implementation issues |
| Date: | 2002-04-02 09:12:27 |
| Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961D97@m0114.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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
Well imho that interpretation would be completely unobvious.
My first guess would have been, that with this syntax the whole transaction
must commit or rollback within 5 seconds.
Thus I think we only need statement_timeout. ODBC, same as JDBC wants it at the
statement handle level. ODBC also provides for a default that applies to all
statement handles of this connection (They call the statement attr QUERY_TIMEOUT,
so imho there is room for interpretation whether it applies to selects only, which
I would find absurd).
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark kirkwood | 2002-04-02 10:01:09 | Re: Re : Solaris Performance - Profiling |
| Previous Message | Robert Schrem | 2002-04-02 08:58:13 | Re: timeout implementation issues, lock timeouts |