On 10/14/2016 01:57 PM, Mario De Frutos Dieguez wrote:
> Hi!
>
> Thank you very much for your quick response :)
>
> We're looking for a solution at plpython level. My two proposals are a
> quick "workaround" that let us interrupt using custom signal handlers in
> the python code at plpython level. But I'm looking for something more solid
> and your proposal, I've been doing this for 3 days hehe, looks great and I
> would LOVE to hear more about it and if you can't guide me a bit more in
> order to fully understand it :)
>
> We've been thinking to make something like the PostGIS handler
> <https://github.com/postgis/postgis/blob/98b2cdb872b5b5bd65606f5bce334d2477b2afc5/postgis/postgis_module.c#L128>
> and
> have multiple signal handlers: one for the Postgres using
> StatementCancelHandler and one for the python code. How does it sound?
Hmm, yeah, I guess that would work too. Or maybe not, if the library
gets preloaded with shared_preload_libraries, because the signal handler
is then overridden in backends. (And the "coreIntHandler" will continue
to point to postmaster's signal handler, which is also wrong.)
Overall, changing signal handlers in an extension seems pretty fragile.
I think adding some kind of a hook mechanism to the backend would be a
much more robust. An extension that wants to get called from
query-cancel signal handler would register a callback, and we would call
the callbacks from the signal handlers in postgres.c.
Aside from SIGINT, a query cancel can also be triggered by a "recovery
conflict", from RecoveryConflictInterrupt(). With an explicit hook, we
can ensure that the hook gets called in all the situations that set
QueryCancelPending. And you'll want to handle ProcDiePending, too.
- Heikki