Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8; format=Flowed
Date: Mon, 24 Jul 2023 12:09:05 -0500
Message-Id: <CUAKGWGPO8EZ.9YCLEP1X976O@gonk>
Cc: <pgsql-hackers@postgresql.org>
Subject: Re: psql not responding to SIGINT upon db reconnection
To: "Gurjeet Singh" <gurjeet@singh.im>
From: "Tristan Partin" <tristan@neon.tech>
References: <CUAJJDVD8L61.2AH6VEEDMTXX3@gonk>
 <CABwTF4ULmrh7v4oY2mjBEfj1LXU_3a10V30QxZfo1+10+z5=AQ@mail.gmail.com>
In-Reply-To: 
 <CABwTF4ULmrh7v4oY2mjBEfj1LXU_3a10V30QxZfo1+10+z5=AQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/CUAKGWGPO8EZ.9YCLEP1X976O%40gonk>
Precedence: bulk

On Mon Jul 24, 2023 at 12:00 PM CDT, Gurjeet Singh wrote:
> On Mon, Jul 24, 2023 at 9:26=E2=80=AFAM Tristan Partin <tristan@neon.tech=
> wrote:
>
> > attached patch
>
> +        /*
> +         * Restore the default SIGINT behavior while within libpq.
> Otherwise, we
> +         * can never exit from polling for the database connection. Fail=
ure to
> +         * restore is non-fatal.
> +         */
> +        newact.sa_handler =3D SIG_DFL;
> +        rc =3D sigaction(SIGINT, &newact, &oldact);
>
>     There's no action taken if rc !=3D 0. It doesn't seem right to
> continue as if everything's fine when the handler registration fails.
> At least a warning is warranted, so that the user reports such
> failures to the community.

If we fail to go back to the default handler, then we just get the=20
behavior we currently have. I am not sure logging a message like "Failed=20
to restore default SIGINT handler" is that useful to the user. It isn't=20
actionable, and at the end of the day isn't going to affect them for the=20
most part. They also aren't even aware that default handler was ever=20
overridden in the first place. I'm more than happy to add a debug log if=20
it is the blocker to getting this patch accepted however.

--=20
Tristan Partin
Neon (https://neon.tech)