Database Reference
In-Depth Information
If you choose to run batch jobs, the syntax must be specific to the OS running the job.
For example, if your pgAgent is running on Windows, your batch jobs should have valid
DOS commands. If you are on Linux, your batch jobs should have valid shell or Bash
commands.
Steps run in alphabetical order, and you can decide what kinds of actions you want to
take upon success or failure of each. You have the option of disabling steps that should
remain dormant but that you don't want to delete because you might reactivate them
later.
Once you have the steps ready, go ahead and set up a schedule to run them. You can set
up intricate schedules with the scheduling screen. You can even set up multiple sched‐
ules.
If you installed pgAgent on multiple servers and have them all pointing to the same
pgAgent database, all these agents by default will execute all jobs.
If you want to run the job on just one specific machine, fill in the
host agent
field when
creating the job. Agents running on other servers will skip the job if it doesn't match
their host name.
pgAgent consists of two parts: the data defining the jobs and the
logging of the job. Log information resides in the pgAgent schema,
usually in
postgres
database; the job agents query the jobs for the
next job to run and then insert relevant logging information in the
database. Generally, both the PostgreSQL server holding the data and
the job agent executing the jobs reside on the same server, but they
are not required to. Additionally, a single PostgreSQL server can ser‐
vice many job agents residing on different servers.
A fully formed job is shown in
Figure 4-19
.
Figure 4-19. pgAgent jobs in pgAdmin
