Re: Scheduler in Postgres

pgsql(at)esiway(dot)net (Marco Colombo) writes:
> On Thu, 16 Dec 2004, Christopher Browne wrote:
>> None of this means forcing it into the database implementation; it
>> just means that it would be useful. "pgcron" sounds like an
>> utterly splendid idea.
>
> Is the Oracle one _just_ that? A cron/at replacement? What about
> porting every UNIX utility to the DB engine (that would be a
> cross-platfrom Unix - wow)? Why don't they put web and application
> server functionality (apache and PHP) in the DB? No, wait... ehm...
> :-)
>
> Seriously, such an application (scheduler) _will_ have to deal with
> OS differences. Interesting things to log about the spawned jobs
> will be different. They way you run then (I don't mean the actual
> system call, think of nice level instead) may be different.

That's well and nice; if I had a "database-driven" cron alternative, I
would use it, possibly on several platforms, as it would provide
compelling advantages over traditional cron. I think it would provide
compelling advantages to my employer, too.

I'm _not_ asking for some "Barneyfied All Encompassing Interface;" I'm
_not_ asking for it to be treated as an integral part of PostgreSQL.
You're picking a strawman argument there, and trying to suggest that's
what I'm looking for. I'm certainly NOT.

I don't want Oracle, but I could use a better cron, and anacron isn't
the answer.

We have some challenges concerning generating reports; I consider that
having a "better scheduler" than cron is one of the pieces of that
particular puzzle.

> I wonder if limiting the application domain to DB-related jobs only
> would help. I mean, it is quite common to run time based procedures
> at DB level, like report generation or table summarization. Usually,
> this activities are driven by _external_ schedulers (cron), via
> scripts that need to connect and _authenticate_, which leads to
> security nightmares.

No, the sorts of things that "pgcron" enables are most certainly _NOT_
reasonably limited to just "DB-related" jobs.

Having an interface providing access to history information about past
jobs enables plenty of things that don't require that the application
cares about databases at all.
--
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)