Re: pg_receivewal and SIGTERM

On Thu, Aug 25, 2022 at 11:19:05AM +0200, Daniel Gustafsson wrote:
> I think this can be argued both for and against backpatching. Catching SIGTERM
> makes a lot of sense, especially given systemd's behavior. On the other hand,
> This adds functionality to something arguably working as intended, regardless
> of what one thinks about the intent.

Sure. My view on this matter is that the behavior of the patch is
more useful to users as, on HEAD, a SIGTERM is equivalent to a drop of
the connection followed by a retry when not using -n. Or do you think
that there could be cases where the behavior of HEAD (force a
connection drop with the backend and handle the retry infinitely in
pg_receivewal/recvlogical) is more useful? systemd can also do
retries a certain given of times, so that's moving the ball one layer
to the other, at the end. We could also say to just set KillSignal to
SIGINT in the docs, but my guess is that few users would actually
notice that until they see how pg_receiwal/recvlogical work with
systemd's default.

FWIW, I've worked on an archiver integration a few years ago and got
annoyed that we use SIGINT while SIGTERM was the default (systemd was
not directly used there but the signal problem was the same, so we had
to go through some loops to make the stop signal configurable, like
systemd).
--
Michael