On Thu, Aug 4, 2011 at 09:11, Andrew Dunstan <and...@dunslane.net> wrote:
>> What *I'd* like is a way to prevent libperl from touching the host >> application's signal handlers at all. Sadly, Perl does not actually >> think of itself as an embedded library, and therefore thinks it owns all >> resources of the process and can diddle them without anybody's >> permission. >> >> > > I'm not sure how perl (or any loadable library) could restrict that in > loaded C code, which many perl modules call directly or indirectly. It's as > open as, say, a loadable C function is in Postgres ;-) You have a gun. It's > loaded. If you point it at your foot and pull the trigger don't blame us. I > think you just need to be very careful about what you do with plperlu. Don't > be surprised if things break. Well we can't prevent perl XS (aka C) from messing with signals (and other modules like POSIX that expose things like sigprocmask, siglongjump etc.) , but we could prevent plperl(u) from playing with signals on the perl level ala %SIG. [ IIRC I proposed doing something about this when we were talking about the whole Safe mess, but I think there was too much other discussion going on at the time :-) ] Mainly the options im thinking about are: 1) if anyone touches %SIG die 2) turn %SIG into a regular hash so people can set/play with %SIG, but it has no real effect. 3) local %SIG before we call their trigger function. This lets signals still work while "in trigger scope" (like we do for %_TD) 4) if we can't get any of the above to work we can save each %SIG handler before and restore them after each trigger call. (mod_perl does something similar so Im fairly certain we should be able to get that to work) Thoughts? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers