Re: elegant and effective way for running jobs inside a database

On Sat, Mar 10, 2012 at 2:59 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

> The devil is in the details, though, pace Mies van der Rohe.
>
> In particular, it's the "tight integration" piece I'm worried about.
>
> What is the postmaster supposed to do if the daemon start fails? What if it
> gets a flood of failures? What access will the daemon have to Postgres
> internals? What OS privileges will it have, since this would have to run as
> the OS postgres user? In general I think we don't want arbitrary processes
> running as the OS postgres user.

So why are the answers to those questions different for a daemon than
for a C function executed from an external client? What additional
exposure is there?

> I accept that cron might not be the best tool for the jobs, since a) its
> finest granularity is 1 minute and b) it would need a new connection for
> each job. But a well written external daemon that runs as a different user
> and is responsible for making its own connection to the database and
> re-establishing it if necessary, seems to me at least as clean a design for
> a job scheduler as one that is stopped and started by the postmaster.

As of this thread, you can see that many people don't agree. Bear in
mind that nobody is trying to prevent you from writing a program in
that way if you believe that. That route will remain available.

It's a key aspect of modular software we're talking about. People want
to have programs that are intimately connected to the database, so
that nobody needs to change the operational instructions when they
start or stop the database.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services