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
signature.asc
Description: PGP signature
