> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 06 March 2005 21:44
> To: Dave Page
> Cc: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] RFC: pgAgent Scheduler Design
>
> Dave Page wrote:
>
> >
> >-----Original Message-----
> >From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> >Sent: Sun 3/6/2005 1:41 PM
> >To: Dave Page
> >Cc: pgadmin-hackers@postgresql.org
> >Subject: Re: [pgadmin-hackers] RFC: pgAgent Scheduler Design
> >
> >
> I don't completely agree. If a job was stuck unexecuted in
> the queue for
> a while, it should run asap, and the next schedule should be
> calculated
> in the future, i.e. a daily job not executed for 5 days shouldn't be
> executed 5x, but only once after pgAgent is up again.
Hmm, not sure about that. I definitely want to hear some other opinions
on this please!!
> This doesn't enable multi agents. There should be a limit on
> threads per
> agent to give other instances a chance.
>
> >The use of multiple agents by the vast majority of people
> seems unlikely to me - especially given the lack of control
> over what runs on what agent. In particular, the majority of
> jobs are likely to be SQL jobs, the distribution of which is
> pretty much irrelevant anyway as all the hard work is done by
> the server. I'm not convinced that many people will want to
> run resource hungry batch jobs that may run on random agent machines.
> >
> >
> Binary jobs (shell jobs) need a system qualifier.
Well that would tie in with the multi-thread model, and the current code
which is broken with multiple agents anyway (because there is nothing to
stop 2 agents grabbing and running the same job at the same time).
Allowing unlimited threads per agent, and allowing a specific system to
be named, we can ensure things start when they should, and can be
properly distributed.
Regards, Dave.
