On Sun, 1 May 2005 23:08:39 -0500Jaime Casanova <systemguards@gmail.com> wrote:
>On 5/1/05, adnandursun@asrinbilisim.com.tr
><adnandursun@asrinbilisim.com.tr> wrote:
>> On Sun, 1 May 2005 14:35:37 -0500
>> Bruno Wolff III <bruno@wolff.to> wrote:
>> >On Sun, May 01, 2005 at 19:57:37 +0300,
>> > adnandursun@asrinbilisim.com.tr wrote:
>> >>
>> >> Listen Tom, write a client software that releases the
>> >> resources / locks that was hold before client power
>is
>> >down
>> >> or client connection was lost.
>> >
>> >If Postgres can tell the connection has been lost then
>it
>> >should roll back the connection.
>>
>> Yes, but, Can PostgreSQL know which connection is lost
>or
>> live or dead ?
>>
>> >The problem is that you can't always
>> >tell if a connection has been lost. All you can do is
>> timeout, either when TCP
>> >times out or some other timeout (such as a statment
>> timeout) that you set.
>>
>> You are right, a timeout parameter must be used for
>that
>> on the backend. a client application never find the
>> previous instance before it crashed. However more than
>one
>> connection was able to be established to PostgreSQL
>> backend..
>>
>> Statement_timeout is just a escape mechanism for
>active
>> transaction. Imagine; you've started a process to update
>> the rows in a table then your PC power was down but you
>> have not sent commit or rollback yet..What will happen
>now
>>
>If you send the update outside a transaction and...
>
>Option 1) ...the client crashes then the update will
>commit, i think.
>If you don't want that send the update inside a
>begin/commit block.
>
>Option 2) ...the server crashes the update will rollback.
>
>
>If you send the update inside a transaction and...
>
>Option 1) ...the client crashes then the update will
>rollback.
>Option 2) ...the server crashes the update will rollback.
>
>Actually, i can't see what's the problem. :)
No, process waits until it is completed..
Adnan DURSUN
ASRIN Bili?im Hiz.Ltd.
