2011/5/23 Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx>: > On 23/05/2011 10:13 AM, jun yang wrote: > >> actually, we will write the procedure in pl/python,then fork a new >> thread or a new process which is easy. > > Yikes. Be careful there - it's not as easy as you think it is. > > Spawning a new thread within a PostgreSQL backend is a very, very, very bad > idea unless you know EXACTLY what you are doing. Do not do it if there is > any alternative. > > As for spawning a new process: a PostgreSQL backend's environment isn't > guaranteed to be what you expect. I don't just mean environment variables. > The most likely surprise will be finding yourself running in quite a > limiting SELinux context if SELinux is present, but I'm sure there are more > possible quirks. Also, on unix/linux, if the backend process that invoked > your helper dies, your helper will be re-parented to init not to the > postmaster, which won't be what you expected. > thanks for the info,i am just not have such deep learn of pg internal, i am on user level,not hacker,so the mail is in pgsql-general,not hacker list. >>> There's been discussion of adding the ability for the postmaster to start >>> helper daemons, and if that were merged you could use a helper started >>> alongside the postmaster to do the work. Right now, though, you're better >>> off doing things how PgAgent etc do it, that is out-of-process via a >>> regular >>> Pg connection. >>> >> then the one sitting between pg and borker is a helper daemon,it is >> great,more info about that? >> PgAgent is nice,i am just wondering why it can't be integrated in >> standard pg install,cause security? functionality? > > Doing just that is sometimes discussed, and I think it'll happen eventually. > First, though, PostgreSQL's postmaster needs to be altered so that it can > start and manage helper programs and daemons. As of now, that hasn't > happened yet, or at least nobody has written a good enough patch that the > core team have been willing to accept it. > >> if helper daemon integrated in pg,the PgAgent can be a helper daemon too. >> i'd like helper daemon can operate like windows service,you can >> disable it,make it mannual start, or auto start with pg. > > Your best bet at the moment is to integrate with operating system service > mechanisms. On Windows, use services. On UNIX/Linux, use the init system. On > Mac OS X, use launchd. > > Part of the reason the postmaster hasn't been altered to support managing > daemons is because some people (understandably) think that that's the OS's > job, and not something PostgreSQL should duplicate. > well,from user viewpoint,i prefer that pg bundle with such function,like extension in pg,the function default is disable.make it easier for those who need it will be a promotion for pg. many commercial db production include such a schedule function, not only for making money,there is user need in practice. > In an ideal world I'd agree with them, but the current computing world is > far from ideal. Every OS is annoyingly different in how it manages daemons, > and many init systems are painfully limited in terms of the kind of events > they can handle. Most can't even handle "If service <x> exits, do <y>". > Monitoring capabilities and the like must be individually provided by each > service if they want to be even a little bit portable. > > Nonetheless, I think that's your best bet right now. > yes,it is so complicated for a common user to do such things. > -- > Craig Ringer > > Tech-related writing at http://soapyfrogs.blogspot.com/ > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
