Re: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <dgustafsson(at)postgresql(dot)org>
Cc: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical
Date: 2022-09-14 15:06:35
Message-ID: 2684964.1663167995@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Daniel Gustafsson <dgustafsson(at)postgresql(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Daniel Gustafsson 2022-09-14 15:21:06 Re: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical
Previous Message Daniel Gustafsson 2022-09-14 14:35:40 pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical