Re: elegant and effective way for running jobs inside a database
От | Christopher Browne |
---|---|
Тема | Re: elegant and effective way for running jobs inside a database |
Дата | |
Msg-id | CAFNqd5Vdt+LLtA560qHRanaWLqwH3JwkDMNRY0i2hM9kGGNHRg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: elegant and effective way for running jobs inside a database (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Tue, Mar 6, 2012 at 12:47 PM, Robert Haas <robertmhaas@gmail.com> wrote: > And also some interface. It'd be useful to have background jobs that > executed either immediately or at a certain time or after a certain > delay, as well as repeating jobs that execute at a certain interval or > on a certain schedule. Figuring out what all that should look like > is, well, part of the work that someone has to do. Certainly. It would seem to make sense to have a database schema indicating this kind of metadata. It needs to be sophisticated enough to cover *enough* unusual cases. A schema duplicating crontab might look something like: create table cron ( id serial primary key, minutes integer[], hours text integer[], dayofmonth integer[], month integer[],dayofweek integer[], command text ); That's probably a bit too minimalist, and that only properly supports one user's crontab. The schema needs to include things like: a) When to perform actions. Several bases for this, including time-based, event-based. b) What actions to perform (including context as to database user, search_path, desired UNIX $PWD, perhaps more than that) c) Sequencing information, including what jobs should NOT be run concurrently. d) Logging. If a job succeeds, that should be noted. If it fails, that should be noted. Want to know start + end times. e) What to do on failure. "Everything blows up" is not a good answer :-). -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
В списке pgsql-hackers по дате отправления: