Обсуждение: pgAgent issues
Preparing my stuff for LinuxTag, I worked a little on pgAdmin's pgAgent support. Apparently, we soon will have a common database (whether the default connect db from initdb or not), agreed between admin developers, so I moved the pgAgent objects under server, since it doesn't make sense to have more than one agent installation per cluster. It will only show up if the initialdb connection has the pgagent schema. Maybe we should rename "initial database" to something reflecting its purpose better, maybe "maintenance connection". 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. 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). 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? Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 19 June 2005 22:03 > To: Dave Page; pgadmin-hackers > Subject: pgAgent issues > > Preparing my stuff for LinuxTag, I worked a little on > pgAdmin's pgAgent > support. Apparently, we soon will have a common database (whether the > default connect db from initdb or not), agreed between admin > developers, > so I moved the pgAgent objects under server, since it doesn't > make sense > to have more than one agent installation per cluster. It will > only show > up if the initialdb connection has the pgagent schema. Maybe > we should > 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. How does your design above cope with running twice on a Monday, and once on a Tuesday? Or, the last day of every month? > 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. Regards, Dave.
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
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 20 June 2005 09:13 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: pgAgent issues > > > 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. OK, well if you can simplify it without loss of functionality, then go ahead. > > 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? No, I think we need to restructure the existing file (I already promised Raphael I'd make it plain text). Perhaps a separate section for each component? Regards, Dave