On 12/4/15 4:15 AM, Peter J. Holzer wrote:
> On 2015-12-03 10:02:18 -0500, Tom Lane wrote:
>> >"Peter J. Holzer"<hjp-pgsql@hjp.at> writes:
>>> > >Can those signals be safely ignored? Just blocking them (so that they
>>> > >are delivered after the UDF finishes) might be safer. But even that may
>>> > >be a problem: If the UDF then executes some SQL, could that rely on
>>> > >signals being delivered? I have no idea.
>> >
>> >The minute you start fooling with a backend's signal behavior, we're
>> >going to politely refuse to support whatever breakage you run into.
> As I understood Jim he was talking about possible changes to postgresql
> to shield UDFs from those signals, not something the author of a UDF
> should do.
No, I was suggesting that:
1) It might possible for Postgres error handling to detect that a signal
had been received since entering a UDF if the UDF reported an error, and
make that information available as part of the standard error report.
2) If there are alarms being set specifically for authentication, they
should probably be cancelled after authentication is successful.
I certainly do NOT think it would be wise to disable all signal handling
during UDF execution. Just for starters, that means that if a UDF went
into an infinite loop your only way to recover would be to PANIC the
entire database. It would probably create a bunch of other problems as well.
In other words, UDFs *must* be capable of handling an interrupt.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com