Re: RFC: pgAgent Scheduler Design

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 05 March 2005 23:16
> To: Dave Page
> Cc: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] RFC: pgAgent Scheduler Design
>
> Sorry, this won't work.
>
> It is mandatory that a "next run" schedule is calculated
> after a job has
> run, and FireSchedule will run when nextRun is >= current_timestamp.

Yes, and that is how it will run - the code snippet I gave was simply to
illustrate how the schedule storage will work, not how the scheduler
will actually run. I fully intend to retain the current method of
pre-calculating the next run time.

> Imagine two jobs scheduled for the very same minute, and only one
> pgAgent running. It will run the first job, which will run
> for lets say
> 2 minutes. After that, the fire time for the second job is
> not due any
> more, so it will run somewhat later, if ever.

Yes, I'm aware of that issue - and even the current design will have
problems in that jobs may stil run late. I think the correct way to
address this is to grab all due jobs, and spawn a separate thread to
handle each. This should allow jobs to actually start when they are
supposed to.

> That's what pga_next_schedule is good for. You'll have quite
> a hard time
> to calulate it from your way of storing schedules, I'm afraid... It's
> somewhat the difference between cron and anacron.

Yes, I realise it's not the easiest thing to do, but I do not believe
it's a major problem that cannot be overcome with a little thought. I
think the trick is to treat each element of the schedule seperately, and
find the next month, then the next day, and lastly the hour and minute
in turn.

Regards, Dave.