On 5/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Sun, 1 May 2005 14:35:37 -0500 > Bruno Wolff III <[EMAIL PROTECTED]> wrote: > >On Sun, May 01, 2005 at 19:57:37 +0300, > > [EMAIL PROTECTED] 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. :) -- Atentamente, Jaime Casanova (DBA: DataBase Aniquilator ;) ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org