Re: scheduler in core

Greg Stark <gsstark(at)mit(dot)edu> writes:
> It'll always be another (set of) processes even if it's "in core". All
> it means to be "in core" is that it will be harder to make
> modifications and you'll be tied to the Postgres release cycle.

Another set of processes all right, but that postmaster is responsible
of, that it starts and ends at the right time.

>> Main advantage over cron or another scheduler being that it'd be part of
>> my transactional backups, of course.
>
> All you need for that is to store the schedule in a database table.
> This has nothing to do with where the scheduler code lives.

Not true. You need custom scripts that will read what's in this database
table and run it at the right timing, care about running more than one
job at the same time when necessary, reports what the outcome was
somewhere, etc.

The simplest would be a query that writes out in cron format the setup
you've made in the database, I suppose. When do you run that query? You
need an untrusted trigger? What happens if your query or script writes a
file cron will not be able to read, or on a server where cron is not
running?

I'm not saying this is any harder that other admin sys stuff we have to
do to operate the systems, just that it seems it would be simpler,
easier and less error prone to be able to schedule database maintenance
from within the database itself, in such a way that the classic dump and
restore process restores the maintenance scripts too.

That would allow for automatic creation of partitions in dev and
pre-prod environments where you install more than one copy of the same
database at once, but would like to avoid maintaining one set of cron
entries per copy.

As said Tom, technically, it's obviously possible not to depend on a
PostgreSQL integrated scheduler. As said JD, it still is a pretty good
idea to provide one in core.

Regards,
--
dim