On Feb 22, 2010, at 5:22 PM, Jaime Casanova wrote:
> On Mon, Feb 22, 2010 at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Dimitri Fontaine <dfontaine@hi-media.com> writes:
>>> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>>> This seems like a solution in search of a problem to me. The most
>>>> salient aspect of such processes is that they would necessarily run
>>>> as the postgres user
>>
>>> The precedent are archive and restore command. They do run as
>>> postgres
>>> user too, don't they?
>>
>> Well, yeah, but you *must* trust those commands because every last
>> bit
>> of your database content passes through their hands. That is not an
>> argument why you need to trust a scheduling facility --- much less
>> the
>> tasks it schedules.
>>
>
> Ok, let's forget the scheduler for a minute... this is not about that
> anymore, is about having the ability to launch user processes when the
> postmaster is ready to accept connections, this could be used for
> launching an scheduler but also for launching other tools (ie:
> pgbouncer, slon daemons, etc)
Just a few questions off the top of my head:
What are the semantics? If you launch a process and it crashes, is
the postmaster responsible for relaunching it? Is there any
additional monitoring of that process it would be expected to do?
What defined hooks/events would you want to launch these processes
from? If you have to kill a backend postmaster, do the auxiliary
processes get killed as well, and with what signal? Are they killed
when you stop the postmaster, and are they guaranteed to have stopped
at this point? Can failing to stop prevent/delay the shutdown/restart
of the server? Etc.
Regards,
David
--
David Christensen
End Point Corporation
david@endpoint.com