Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)
От | Tom Lane |
---|---|
Тема | Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role) |
Дата | |
Msg-id | 17594.1332795473@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role) (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Cross-backend signals and administration (Was: Re:
pg_terminate_backend for same-role)
Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role) |
Список | pgsql-hackers |
Magnus Hagander <magnus@hagander.net> writes: > I wasn't aware that was the reason there. I think it was the general > "leftovers" from previous times. When we first created > pg_terminate_backend() there was a general thought that it might not > be safe to just SIGTERM a backend to make it quit. Not just "might not be safe" - it was demonstrably buggy in the beginning. > A bunch of fixes > were put in place to make it more safe, but I'm not sure anybody > actually declared it fully safe. We never did, we only said we didn't know of more bugs. > I'm not sure - perhaps we're past that worry these days? I'm not. I still wouldn't trust SIGTERMing an individual backend in a production database. It'll probably work, but what if it doesn't? Best-case scenario is you'll need to do a panic shutdown to clear the stuck lock or whatever that the backend left behind. (Once you've diagnosed the problem, that is.) Now, in a case where the alternative is a database shutdown anyway, you might as well try it. But it's the kind of tool you only want to hand to responsible adults, which is why it's superuser-only at the moment. I'm not sure we should be encouraging people to fire that weapon indiscriminately. regards, tom lane
В списке pgsql-hackers по дате отправления: