Re: [HACKERS] PID of backend
От
Maarten Boekhold
Тема
Re: [HACKERS] PID of backend
Дата
Msg-id
375D1F62.6C50C373@tibco.com
Список
Дерево обсуждения
PID of backend Dmitry Samersoff <dms@wplus.net>
Re: [HACKERS] PID of backend Oleg Bartunov <oleg@sai.msu.su>
Re: [HACKERS] PID of backend Dmitry Samersoff <dms@wplus.net>
Re: [HACKERS] PID of backend Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PID of backend Dmitry Samersoff <dms@wplus.net>
Re: [HACKERS] PID of backend Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] PID of backend Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PID of backend The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] PID of backend Dmitry Samersoff <dms@wplus.net>
Tom Lane wrote: > > Meanwhile, I still say that getting rid of a backend via kill() is a > dangerous and unnecessary "recovery" mechanism. What's wrong with > just closing and reopening the connection instead? I don't know about later versions of pgsql, but I've a 6.3.2 system running on a production system, and every once in a while one of the backends will go crazy and eat CPU. This system is on a web server, and processes requests tru a CGI script. For the administrator (i.e. me), it is impossible to close the CGI<-->backend connection (the backend will keep running after I kill off the CGI script). Only thing that will get things back in order is to kill that backend (which sometimes also requires me to restart the postmaster, probably because of some shared mem corruption). Maarten ps. This system is not a priority for me, I', quote happy with how it's running, so please don't tell me to upgrade or give me any other suggestions. -- Maarten Boekhold, boekhold@tibco.com TIBCO Finance Technology Inc. The Atrium Strawinskylaan 3051 1077 ZX Amsterdam, The Netherlands tel: +31 20 3012158, fax: +31 20 3012358 http://www.tibco.com
В списке pgsql-hackers по дате отправления