Re: Feature freeze date for 8.1

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