Re: how to start a procedure after postgresql started. - Mailing list pgsql-general

2011/5/23 Craig Ringer <craig@postnewspapers.com.au>:
> 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/
>