Re: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical
Date
Msg-id 2684964.1663167995@sss.pgh.pa.us
Whole thread Raw
In response to pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical  (Daniel Gustafsson <dgustafsson@postgresql.org>)
Responses Re: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical  (Daniel Gustafsson <dgustafsson@postgresql.org>)
List 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 by date:

Previous
From: Daniel Gustafsson
Date:
Subject: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical
Next
From: Daniel Gustafsson
Date:
Subject: Re: pgsql: Handle SIGTERM in pg_receivewal and pg_recvlogical