From: Paul Ramsey <pramsey@cleverelephant.ca>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_BEC8EF84-7969-4B3C-806C-4BB8E32A3DC2"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
Subject: Converting pqsignal to void return
Message-Id: <4E796D56-79B5-4447-9DA7-5428BC1A6B53@cleverelephant.ca>
Date: Wed, 22 Jan 2025 07:57:52 -0800
Cc: Nathan Bossart <nathandbossart@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Archived-At: <https://www.postgresql.org/message-id/4E796D56-79B5-4447-9DA7-5428BC1A6B53%40cleverelephant.ca>
Precedence: bulk


--Apple-Mail=_BEC8EF84-7969-4B3C-806C-4BB8E32A3DC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Nathan,=20

I just ran across this change when a bunch of CI=E2=80=99s I run barfed.=20=


=
https://github.com/postgres/postgres/commit/d4a43b283751b23d32bbfa1ecc2cad=
2d16e3dde9

The problem we are having in extension land is that we often run =
functions in external libraries that take a long time to return, and we =
would like to ensure that PgSQL users can cancel their queries, even =
when control has passed into those functions.

The way we have done it, historically, has been to take the return value =
of pqsignal(SIGINT, extension_signint_handler) and remember it, and =
then, inside extension_signint_handler, call the pgsql handler once we =
have done our own business.=20

https://github.com/pramsey/pgsql-http/blob/master/http.c#L345

It is possible we have been Doing It Wrong all this time, and would love =
some pointers on the right way to do this.

Alternatively, if we have a valid use case, it would be nice to have the =
return value from pqsignal() back.

Thanks!

Paul=20=

--Apple-Mail=_BEC8EF84-7969-4B3C-806C-4BB8E32A3DC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: =
after-white-space;">Nathan,&nbsp;<div><br></div><div>I just ran across =
this change when a bunch of CI=E2=80=99s I run =
barfed.&nbsp;</div><div><br></div><div><a =
href=3D"https://github.com/postgres/postgres/commit/d4a43b283751b23d32bbfa=
1ecc2cad2d16e3dde9">https://github.com/postgres/postgres/commit/d4a43b2837=
51b23d32bbfa1ecc2cad2d16e3dde9</a></div><div><br></div><div>The problem =
we are having in extension land is that we often run functions in =
external libraries that take a long time to return, and we would like to =
ensure that PgSQL users can cancel their queries, even when control has =
passed into those functions.</div><div><br></div><div>The way we have =
done it, historically, has been to take the return value of =
pqsignal(SIGINT, extension_signint_handler) and remember it, and then, =
inside extension_signint_handler, call the pgsql handler once we have =
done our own business.&nbsp;</div><div><br></div><div><a =
href=3D"https://github.com/pramsey/pgsql-http/blob/master/http.c#L345">htt=
ps://github.com/pramsey/pgsql-http/blob/master/http.c#L345</a></div><div><=
br></div><div>It is possible we have been Doing It Wrong all this time, =
and would love some pointers on the right way to do =
this.</div><div><br></div><div>Alternatively, if we have a valid use =
case, it would be nice to have the return value from pqsignal() =
back.</div><div><br></div><div>Thanks!</div><div><br></div><div>Paul&nbsp;=
</div></body></html>=

--Apple-Mail=_BEC8EF84-7969-4B3C-806C-4BB8E32A3DC2--