Re: Server instrumentation: pg_terminate_backend, pg_reload_conf
От | Andreas Pflug |
---|---|
Тема | Re: Server instrumentation: pg_terminate_backend, pg_reload_conf |
Дата | |
Msg-id | 42A58A1D.9030904@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: Server instrumentation: pg_terminate_backend, pg_reload_conf (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-patches |
Bruce Momjian wrote: > Andreas Pflug wrote: > >>Bruce Momjian wrote: >> >>>Andreas Pflug wrote: >>> >>> >>>>This patch reenables pg_terminate_backend, allowing (superuser only, of >>>>course) to terminate a backend. As taken from the discussion some weeks >>>>earlier, SIGTERM seems to be used quite widely, without a report of >>>>misbehavior so while the code path is officially not too well tested, >>>>in practice it's working ok and helpful. >>> >>> >>>I thought we had a discussion that the places we accept SIGTERM might be >>>places that can exit if the postmaster is shutting down, but might not >>>be places we can exit if the postmaster continues running, e.g. holding >>>locks. Have you checked all the places we honor SIGTERM to check that >>>we are safe to exit? I know Tom had concerns about that. >> >>My patch is purely to enable a supervisor to issue a SIGTERM using a >>pgsql client, instead of doing it from a server command line. It's not >>meant to fix the underlying problems. > > > We don't support sending SIGTERM from the server command line to > individual backends, so why add support for it in SQL? I don't want to slip into discussion whether it's good to SIGTERM a backend or not, it is in use. So drop it if you don't like clients to have the same facilities as console users. BTW, I got a lot of other instrumentation stuff pending, which I originally wanted to post one by one to allow individual discussion but I'm running out of time for feature freeze. Apparently I'll have to post all at once. Regards, Andreas
В списке pgsql-patches по дате отправления: