From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, adnandursun(at)asrinbilisim(dot)com(dot)tr, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Feature freeze date for 8.1 |
Date: | 2005-05-01 15:37:47 |
Message-ID: | 24597.1114961867@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The problem, as I understand it, is that if you have a long-running
> query and the client process disappears, the query keeps running and
> holds whatever resources it may have until it finishes.
There is a trivial solution for this: it's called statement_timeout.
If the concern is that a process may block other processes for a long
time, what does it matter whether the client is still connected or not?
It's the long-running command in itself that is the problem. So you
limit the time the command can run.
It might be interesting to think about a transaction_timeout as well,
to bound the time locks can be held. But none of this has anything
to do with "high availability" as I understand the term. It looks
more like a forcing function to make your users fix poorly-written
client software ;-)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | adnandursun | 2005-05-01 16:34:40 | Re: Feature freeze date for 8.1 |
Previous Message | Tom Lane | 2005-05-01 15:29:42 | Re: SPI bug. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-01 15:58:39 | Re: Problem with Create Domain example |
Previous Message | Dennis Bjorklund | 2005-05-01 14:56:13 | Re: Feature freeze date for 8.1 |