Re: SIGHUP not received by custom bgworkers if postmaster is notified
От | Michael Paquier |
---|---|
Тема | Re: SIGHUP not received by custom bgworkers if postmaster is notified |
Дата | |
Msg-id | CAB7nPqQ-ccL9Q7wxpWNaG5Zs-hMLh_ayQb=rM2=+PXtWd+8ogw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SIGHUP not received by custom bgworkers if postmaster is notified (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: SIGHUP not received by custom bgworkers if
postmaster is notified
|
Список | pgsql-hackers |
Hi all,
Please find attached a simple example of bgworker that logs a message each time a SIGTERM or SIGHUP signal is received by it:
- "hello signal: processed SIGHUP" when SIGHUP is handled by my example
- "hello signal: processed SIGTERM" when SIGTERM is handled by my example
With the current master code, here is what I get:
$ for i in {1..5}; do pg_ctl reload -D ~/bin/pgsql/master/; sleep 1; done
server signaled
server signaled
server signaled
server signaled
server signaled
$ cat ~/bin/pgsql/master/pg_log/postgresql-2013-03-23_112246.log
LOG: starting background worker process "hello signal worker"
LOG: database system was shut down at 2013-03-23 11:22:46 JST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
LOG: received SIGHUP, reloading configuration files
LOG: received SIGHUP, reloading configuration files
LOG: received SIGHUP, reloading configuration files
LOG: received SIGHUP, reloading configuration files
LOG: received SIGHUP, reloading configuration files
SIGHUP is not received by my bgworker. But SIGTERM is:
$ tail -n 5 ~/bin/pgsql/master/pg_log/postgresql-2013-03-23_112246.log
LOG: autovacuum launcher shutting down
LOG: hello signal: processed SIGTERM
LOG: worker process: hello signal worker (PID 2873) exited with exit code 0
LOG: shutting down
LOG: database system is shut down
Now, if I apply my fix and redo the same tests, here is what I get:
$ for i in {1..5}; do pg_ctl reload -D ~/bin/pgsql/master/; sleep 1; done
server signaled
server signaled
server signaled
server signaled
server signaled
$ cat ~/bin/pgsql/master/pg_log/postgresql-2013-03-23_113315.log
LOG: starting background worker process "hello signal worker"
LOG: database system was shut down at 2013-03-23 11:33:14 JST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
LOG: received SIGHUP, reloading configuration files
LOG: hello signal: processed SIGHUP
LOG: received SIGHUP, reloading configuration files
LOG: hello signal: processed SIGHUP
LOG: received SIGHUP, reloading configuration files
LOG: hello signal: processed SIGHUP
LOG: received SIGHUP, reloading configuration files
LOG: hello signal: processed SIGHUP
LOG: received SIGHUP, reloading configuration files
LOG: hello signal: processed SIGHUP
So SIGHUP is now correctly managed by the bgworker. As well as SIGTERM:
$ pg_ctl st: pg_ctl stop -D ~/bin/pgsql/master/
waiting for server to shut down.... done
server stopped
ioltas@nukkle:~/bin/extra(linux OK)$ tail -n 5 ~/bin/pgsql/master/pg_log/postgresql-2013-03-23_113315.log
LOG: hello signal: processed SIGTERM
LOG: autovacuum launcher shutting down
LOG: worker process: hello signal worker (PID 13781) exited with exit code 0
LOG: shutting down
LOG: database system is shut down
It would be great to get that fixed.
Thanks.
--
Michael
Please find attached a simple example of bgworker that logs a message each time a SIGTERM or SIGHUP signal is received by it:
- "hello signal: processed SIGHUP" when SIGHUP is handled by my example
- "hello signal: processed SIGTERM" when SIGTERM is handled by my example
With the current master code, here is what I get:
$ for i in {1..5}; do pg_ctl reload -D ~/bin/pgsql/master/; sleep 1; done
server signaled
server signaled
server signaled
server signaled
server signaled
$ cat ~/bin/pgsql/master/pg_log/postgresql-2013-03-23_112246.log
LOG: starting background worker process "hello signal worker"
LOG: database system was shut down at 2013-03-23 11:22:46 JST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
LOG: received SIGHUP, reloading configuration files
LOG: received SIGHUP, reloading configuration files
LOG: received SIGHUP, reloading configuration files
LOG: received SIGHUP, reloading configuration files
LOG: received SIGHUP, reloading configuration files
SIGHUP is not received by my bgworker. But SIGTERM is:
$ tail -n 5 ~/bin/pgsql/master/pg_log/postgresql-2013-03-23_112246.log
LOG: autovacuum launcher shutting down
LOG: hello signal: processed SIGTERM
LOG: worker process: hello signal worker (PID 2873) exited with exit code 0
LOG: shutting down
LOG: database system is shut down
Now, if I apply my fix and redo the same tests, here is what I get:
$ for i in {1..5}; do pg_ctl reload -D ~/bin/pgsql/master/; sleep 1; done
server signaled
server signaled
server signaled
server signaled
server signaled
$ cat ~/bin/pgsql/master/pg_log/postgresql-2013-03-23_113315.log
LOG: starting background worker process "hello signal worker"
LOG: database system was shut down at 2013-03-23 11:33:14 JST
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
LOG: received SIGHUP, reloading configuration files
LOG: hello signal: processed SIGHUP
LOG: received SIGHUP, reloading configuration files
LOG: hello signal: processed SIGHUP
LOG: received SIGHUP, reloading configuration files
LOG: hello signal: processed SIGHUP
LOG: received SIGHUP, reloading configuration files
LOG: hello signal: processed SIGHUP
LOG: received SIGHUP, reloading configuration files
LOG: hello signal: processed SIGHUP
So SIGHUP is now correctly managed by the bgworker. As well as SIGTERM:
$ pg_ctl st: pg_ctl stop -D ~/bin/pgsql/master/
waiting for server to shut down.... done
server stopped
ioltas@nukkle:~/bin/extra(linux OK)$ tail -n 5 ~/bin/pgsql/master/pg_log/postgresql-2013-03-23_113315.log
LOG: hello signal: processed SIGTERM
LOG: autovacuum launcher shutting down
LOG: worker process: hello signal worker (PID 13781) exited with exit code 0
LOG: shutting down
LOG: database system is shut down
It would be great to get that fixed.
Thanks.
--
Michael
Вложения
В списке pgsql-hackers по дате отправления: