8 comments

[ 3.3 ms ] story [ 32.3 ms ] thread
It's unclear - What is this supposed to be better than, and what about it is supposed to better?
It seems to me it's extremely clear from the first paragraph - it's supposed to be better the pgagent, and the second paragraph lists all the new features that make it better then pgagent.
It's unclear because the second paragraph is about why the replacement is compatible with pgAgent, literally, "The reason for..." - not that it is a replacement.

It could also be a replacement for something else that runs on top of pgAgent, or something else that doesn't, and one of the features is that this is compatible.

Does that make sense?

Right in the second paragraph:

> The reason for writing a pgAgent compatible job scheduler is to be able to utilize the tools already in place for pgAgent in the pgAdmin UI, minimizing the pain of switching for existing pgAgent users (uses the same database schema), and provide a more stable and feature rich implementation of the agent.

So pgAgent: https://www.pgadmin.org/docs/dev/pgagent.html is what it's supposed to be better than, but also compatible with. It uses the pgAgent database schema, and UI built into pgAdminIII/4.

Now how it's better...good point. Not very obvious to someone who isn't familiar with pgAgent already.

Everything listed under Additional Features is something which is available with jpgAgent and is not available in regular pgAgent.

So a quick list of additional features:

1. Job / job step timeouts (fail a job if it's taken longer than x time)

2. Email notifications on jobs and job steps which can notify you of the status

3. Optionally run job steps in parallel.

4. Manually kill a specific job (there is no way to do that in pgAgent)

5. Good logging (as opposed to almost non-existent logging).

6. Is an actual stable agent. It won't crash on you without warning and leave you wondering why your jobs suddenly stopped running.

Wow, great project. I worked in a place that uses pgAgent heavily, and this address all major pain point with it, aka, parallel steps and max parallel job.
Really appreciate the feedback. Yeah, those were big pain points for me too... I originally wrote v1 over a weekend because I was getting really frustrated with pgAgent crashing on me at random, and jobs would just stop working with no notification or anything. After that I decided to add some of the features I missed from Sql Server Agent, and it kinda evolved from there.

At this point i've got a server that's been running the agent for 6 months with 0 down time, so i'd consider that a success compared to the weekly downtime i'd have at random with pgAgent. Plus the job failure notifications are a life saver for me.