Thread: pgAgent bugs?

In job.cpp, it has this code to get the next job step:

    DBresult *steps=threadConn->Execute(
        wxT("SELECT jstid, jstkind, jstdbname, jstcode, jstonerror ")
        wxT("  FROM pgagent.pga_jobstep ")
        wxT(" WHERE jstenabled ")
        wxT("   AND jstjobid=") + jobid +
        wxT(" ORDER BY jstname, jstid"));

If I had a job with step 1 called Zebra and step 2 called Apple, the above
query would get and then execute step 2 first because of the order by
clause.

I also noticed with version 1.8 of the UI, if I change the On Error flags,
nothing seems to happen.  If I insert a new step, I can make it Succeed,
Fail, or Ignore but changes to this field using pgAdmin after the step has
been created are ignored.


Jon

Roberts, Jon wrote:
> In job.cpp, it has this code to get the next job step:
>
>     DBresult *steps=threadConn->Execute(
>         wxT("SELECT jstid, jstkind, jstdbname, jstcode, jstonerror ")
>         wxT("  FROM pgagent.pga_jobstep ")
>         wxT(" WHERE jstenabled ")
>         wxT("   AND jstjobid=") + jobid +
>         wxT(" ORDER BY jstname, jstid"));
>
> If I had a job with step 1 called Zebra and step 2 called Apple, the above
> query would get and then execute step 2 first because of the order by
> clause.

This is intentional - for the same reason trigger execution is ordered
by name in PostgreSQL. It allows you to control the order of step
execution rather than have it fixed by the order in which you create the
steps.

> I also noticed with version 1.8 of the UI, if I change the On Error flags,
> nothing seems to happen.  If I insert a new step, I can make it Succeed,
> Fail, or Ignore but changes to this field using pgAdmin after the step has
> been created are ignored.

Yup - thats a bug. Fixed for 1.8.1 - thanks.

Regards, Dave.