Re: Feature freeze date for 8.1

On 5/1/05, adnandursun(at)asrinbilisim(dot)com(dot)tr
<adnandursun(at)asrinbilisim(dot)com(dot)tr> wrote:
> On Sun, 1 May 2005 14:35:37 -0500
> Bruno Wolff III <bruno(at)wolff(dot)to> wrote:
> >On Sun, May 01, 2005 at 19:57:37 +0300,
> > adnandursun(at)asrinbilisim(dot)com(dot)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. :)

--
Atentamente,
Jaime Casanova
(DBA: DataBase Aniquilator ;)