Skip site navigation (1) Skip section navigation (2)

Re: pgAgent issues

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: pgAgent issues
Date: 2005-06-20 08:12:43
Message-ID: 42B67A7B.8030608@pse-consulting.de (view raw or flat)
Thread:
Lists: pgadmin-hackers
Dave Page wrote:

>>rename "initial database" to something reflecting its purpose better, 
>>maybe "maintenance connection".
> 
> 
> OK - sounds reasonable. I wasn't overly happy with the previous location
> of the node anyway precisely because of that.


> 
> 
>>The current way to select a schedule seems misleading to me. 
>>I checked 
>>minute 02, minute 07, hour 02, hour 05 and effectively don't 
>>know what 
>>that really means. 
> 
> 
> It's the same as cron - it should run at 02:02, 02:07, 05:02 and 05:07,
> every day of the week.
> 
> 
>>I think we should reduce the scheduling a little: 
>>instead of two panels "Days" and "Times" only "Schedule", with a 
>>selection of yearly, monthly, weekly", daily and hourly (first stage)
>>and a checklistbox/datepicker/timespin that changes accordingly.
>>For example if I select daily I can check 02, 05 and 08 to 
>>have the job 
>>run three times a day. If sensible, a common minutes control might be 
>>added (might already be overkill).
> 
> 
> Well we did discuss this at length on list before I implemented it, so
> I'm not overly keen to change it now.

I understand that, but I wasn't aware of the consequences on the gui. 
The current design seems too confusing.
> 
> How does your design above cope with running twice on a Monday, and once
> on a Tuesday?

This would be two schedules, e.g. mo and tue at 20:00, and mo at 08:00. 
Since we support multiple schedules, there's no need to support 
multiplicity in schedules itself.

> Or, the last day of every month?

That's monthly on the 32. day.

> 
> 
> 
>>My initial design allowed a job's database to be NULL, 
>>indicating "every 
>>database in this cluster". Now it's restricted to NOT NULL, 
>>but '' still 
>>allowed which should indicate the same as previously NULL, 
>>does pgAgent 
>>work that way?
> 
> 
> Nope. Your design as committed had no such functionality (except for
> allowing NULL's in the db field) so I wasn't aware that you had such
> functionality in mind. Feel free to add it if you like.

Won't find the time shortly, should go on a todo-list. Should we create 
a separate file for pgagent?

Regards,
Andreas

In response to

pgadmin-hackers by date

Next:From: Dave PageDate: 2005-06-20 08:16:15
Subject: Re: pgAgent issues
Previous:From: Dave PageDate: 2005-06-20 07:18:12
Subject: Re: pgAgent issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group