On Feb 22, 2010, at 5:22 PM, Jaime Casanova wrote:
On Mon, Feb 22, 2010 at 4:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Dimitri Fontaine <dfonta...@hi-media.com> writes:
Tom Lane <t...@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
da...@endpoint.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
