Postgres Pro
Downloads
Home   >   mailing lists

Re: signal handling in plpython - Mailing list pgsql-hackers

From Mario De Frutos Dieguez
Subject Re: signal handling in plpython
Date
Msg-id CAFYwGJ1vDhwRj5h1Eigs4yF58EFk+ehbUZyRiVpN41ourh42AA@mail.gmail.com
Whole thread Raw
In response to Re: signal handling in plpython  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tree view
Hi!

Following your ideas I've made a test [here], only in plpython and seems to works pretty well. I've to make more tests and execute the postgres regress too.

This ad-hoc solution could be enough for now, we don't have shared_preload_libraries as Heikki pointed, because in the next week we need to be able to interrupt plpython functions.

But, I would REALLY LOVE to implement a proper solution for this case, making hooks in Postgres for extensions like Heikki propose or any other proposal. I'm really enjoying to work in the Postgres internals
and at least I'd like to finish this PATCH.

Any suggestion on what do I need to read, similar cases, advices, etc?

Again thank you very much for your time and you invaluable help.

Mario



2016-10-14 15:22 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 10/14/2016 04:05 PM, Tom Lane wrote:
>> I wrote:
>>> Py_AddPendingCall is safe to call from a signal handler?  That would
>>> be ... quite remarkable.

> Yes, I believe it is.

> https://github.com/python/cpython/blob/4b71e63b0616aa2a44c9b13675e4c8e3c0157481/Python/ceval.c#L422

I don't know whether to laugh or cry, but that code is a joke.  Just
silently fail if you can't get the lock?

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Renaming of pg_xlog and pg_clog
Next
From: Christoph Berg
Date:
Subject: Re: process type escape for log_line_prefix