Re: Feature freeze date for 8.1

Поиск
Список
Период
Сортировка
От
Тема Re: Feature freeze date for 8.1
Дата
Msg-id web-95855903@mail3.doruk.net.tr
обсуждение исходный текст
Ответ на Re: Feature freeze date for 8.1  (Bruno Wolff III <bruno@wolff.to>)
Ответы Re: Feature freeze date for 8.1
Список pgsql-hackers
On Sun, 1 May 2005 14:35:37 -0500Bruno 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
? Example Codes ;

-- Client Side of Codes

1. send statement_timeout = 10;
2. start a transaction;
3. start to update table;   ** connection is lost here
4. commit;

Best Regards,

Adnan DURSUN
ASRIN Bilişim Hiz.Ltd.
Ankara / TURKEY


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruno Wolff III
Дата:
Сообщение: Re: Feature freeze date for 8.1
Следующее
От: Andrew Dunstan
Дата:
Сообщение: custom guc vars