Re: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical
От | Tom Lane |
---|---|
Тема | Re: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical |
Дата | |
Msg-id | 2684964.1663167995@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical (Daniel Gustafsson <dgustafsson@postgresql.org>) |
Ответы |
Re: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical
|
Список | pgsql-committers |
Daniel Gustafsson <dgustafsson@postgresql.org> writes: > Since pg_recvlogical is also supposed to run as a daemon, teach it about > SIGTERM as well and update the documentation to match. While in there, > change pg_receivewal's time_to_stop to be sig_atomic_t like it is in > pg_recvlogical. While looking at this commit, I wondered why both of those programs are declaring their signal handlers like static void sigint_handler(int signum) rather than our standard convention static void pmdie(SIGNAL_ARGS) Evidently we don't (any longer?) have any platforms where SIGNAL_ARGS is non-default, but that still doesn't make this good coding. More than once I've grepped for SIGNAL_ARGS to locate signal handlers. Hmm, looks like same mistake in pg_waldump ... barring objection, I'm going to run around and fix those. I also notice that port.h has typedef void (*pqsigfunc) (int signo); extern pqsigfunc pqsignal(int signo, pqsigfunc func); which is a bit inconsistent with the idea that SIGNAL_ARGS might be different from that. Shouldn't we declare it as typedef void (*pqsigfunc) (SIGNAL_ARGS); ?? I'm definitely going to do that for testing, because then I can alter SIGNAL_ARGS to help me find any other stragglers. regards, tom lane
В списке pgsql-committers по дате отправления: