| From: | Robert Schrem <robert(dot)schrem(at)WiredMinds(dot)de> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: timeout implementation issues, lock timeouts |
| Date: | 2002-04-02 08:58:13 |
| Message-ID: | 200204020843.g328hmb10109@imap.wiredminds.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Monday 01 April 2002 20:18, Bruce Momjian wrote:
> Tom Lane wrote:>
> Agreed, only one timeout.
> ...
We have (at least) two ortogonal reasons why we want
to abort a long running transaction:
- The long running transaction might compute a result
we are not interesed anymore (because it just takes
too long to wait for the result). We do NOT always
know in advance how patient we will be to wait for
the result. Therefore I think the client should tell
the server, when his client (user?) got impatinet
and aborted the whole transaction...
- The long running transaction might hold exclusive locks
and therefore decreases (or even nullifies) the overall
concurrency. We want to be able to disallow this by design.
I think a nice timout criteria would be a maximum lock time
for all resources aquired exclusivly within a transaction.
This would then affect transaction timeouts as well as statement
timeouts with the advantage, the get concurrency guaratees.
Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zeugswetter Andreas SB SD | 2002-04-02 09:12:27 | Re: timeout implementation issues |
| Previous Message | Darko Prenosil | 2002-04-02 08:25:44 | Dblink and ISDN |