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 по дате отправления: