On Sun, Apr 14, 2024 at 11:49 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Dmitry Koterov <dmitry.kote...@gmail.com> writes:
> > I wish it was zsh... I tested it with zsh, but with bash (and with
> > low-level kill syscall), I observed the same effect unfortunately.
>
> > So it's still a puzzle.
>
> > 1. Even more, when I send a kill() low-level syscall using e.g. Perl - perl
> > -e 'kill("INT", 16107)' - it is the same.
> > 2. If any other program but psql is used (e.g. vim or my custom Perl script
> > which ignores SIGINT), the effect is not reproducible.
>
> > Can it be e.g. readline? Or something related to tty or session settings
> > which psql could modify (I did not find any in the source code though).
>
> OK, I tried dtruss'ing psql on macOS. What I see is that with
> Apple's libedit, the response to SIGINT includes this:
>
> kill(0, 2) = 0 0
>
> that is, "SIGINT my whole process group". If I build with libreadline
> from MacPorts, I just see
>
> kill(30902, 2) = 0 0
>
> (30902 being the process's own PID). I'm not real sure why either
> library finds it necessary to re-signal the process --- maybe they
> trap SIGINT and then try to hide that by reinstalling the app's
> normal SIGINT handler and re-delivering the signal. But anyway,
> libedit seems to be vastly exceeding its authority here. If
> signaling the whole process group were wanted, it would have been
> the responsibility of the original signaller to do that.
Probably to intercept SIGWINCH -- I assume it's trying to propagate
the signal to the "real" signal handler, but it's propagating it a
little too far.
https://github.com/NetBSD/src/blob/1de18f216411bce77e26740327b0782976a89965/lib/libedit/sig.c#L110
