On Mon, 02 May 2005 12:05:45 +1000
Neil Conway <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> statement_timeout is not a solution if many processes
>are
>> waiting the resource.
>
>Why not?
Imagine a process locked some rows to update and process
codes like that ;
-- Sample Client Codes here :
1. Start a Transaction
2. Set statement_timeout to 10000 or any value..
3. Update the rows
* after update is completed the connection was lost
and now commit keyword couldnt be sent
4. send commit to postgresql
Above, because "update" is completed the
statement_timeout is not effected anymore to cancel
query..And others processes that waits same resources /
rows are waiting now...
>I think the only problem with using statement_timeout for
>this purpose is that the client connection might die
>during a long-running transaction at a point when no
>statement is currently executing. Tom's suggested
>transaction_timeout would be a reasonable way to fix this.
>Adnan, if you think this is such a significant problem (I
>can't say that I agree), I'd encourage you to submit a
>patch.
Ok Neil, a transaction_timeout parameters solve this, but
this is worst case.. some ppl uses MSADO conneciton
component and ADO conneciton has an attributes that send
"start transaction" after a commit or sends "start
transaction" after a rollback so, evertime has a
transaction on conneciton / session..
Adnan DURSUN
ASRIN Bilişim Hiz.Ltd.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
