On Mon, 02 May 2005 12:05:45 +1000Neil Conway <neilc@samurai.com> wrote:
>adnandursun@asrinbilisim.com.tr 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
completedthe 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.