Tangential since it's not PG related but I'm more and more moving away from cron and I prefer using systemd timers (I'm on RHEL at work). I just find the interface to list and manager timers better and I can just handle everything like a systemd service anyways.
jimis 9 days ago [-]
What is the systemd equivalent for `service crond stop` and later `service crond start`?
In other words, I want to disable all jobs for some time (for benchmarking) and then bring them back up.
sherburt3 9 days ago [-]
Maybe you could make a target unit file like “jobs.target” and in your timer unit files do “WantedBy=jobs.target”. Then you could do “systemctl start/stop jobs.target”
r2_pilot 9 days ago [-]
First, list and save the currently active timers:
```bash
systemctl list-timers --state=active --no-legend | awk '{print $NF}' > /tmp/active_timers.txt
```
Stop all active timers:
```bash
sudo systemctl stop $(cat /tmp/active_timers.txt)
```
Later, restart the previously active timers:
```bash
sudo systemctl start $(cat /tmp/active_timers.txt)
```
NeutralForest 8 days ago [-]
Like the others said, you have to list them and save it somewhere, it could be better in that regard.
samtheprogram 9 days ago [-]
I would try *.timer. If you’re in zsh, quote it.
zie 9 days ago [-]
I have nothing against pg_boss[0] from the articel (I don't know anything about it), but there are plenty of queues and crons and schedulers for PG
> As a rule of thumb, if you're processing less than 1000 jobs per day or your jobs are mostly lightweight operations (like sending emails or updating records), you can stick with this solution.
This seems... excessively low? Chancy is on the heavier side and happily does many millions of jobs per day. Postgres has no issue with such low throughput, even on resource constrained systems (think a $5 vps). Maybe they meant 1000 per second?
zie 9 days ago [-]
I missed that. That does seem very small, 1k jobs/day is nothing.
Chancy also looks pretty neat. Thanks for sharing!
Cron isn't an acronym; it's not normally written in all caps.
Cron's name originates from Chronos, at least according to Wikipedia.
tbrownaw 9 days ago [-]
I can't check at the moment, but IIRC the output of `ps` on $employer's AIX boxes disagrees about it not being all-caps.
7 days ago [-]
verdverm 9 days ago [-]
I recently used PG-Boss to setup jobs to refresh auth tokens in the background. Very easy to use, would recommend taking a look. Docs are a bit minimal, but there's not that much to it either. (https://timgit.github.io/pg-boss/#/)
You don't need WASP for any of this, certainly not worth learning their custom DSL for it. Two of their points about how it makes it better are moot, setting queue names (one line of code) and type safety (you should be using TS already). I've not seen the value in their abstractions and indirection.
OJFord 8 days ago [-]
Or the aptly named pg_cron which is in RDS for example. TFA is just a marketing piece for Wasp, presumably to improve its SEO since 'postgres cron' more obviously gets you to pg_cron otherwise.
jackb4040 8 days ago [-]
I have a node app that has one-off scheduled tasks. Between node-cron and real Linux cron, I went with real cron because node-cron just polls every second, which is extremely inefficient and I'm on a free tier.
How does your library work in this regard? If my node server is down, will my scheduled tasks still execute? I notice you have a .start() method, what does that do? Is it polling periodically?
pg_cron is for pg specific cron tasks. You use pg_cron to truncate a table, compute pg views, values, aggregates, etc. Basically just running PG queries on a CRON schedule.
pg_cron itself won't run an external script for you. Like you can't do
you can use pg_cron to insert a job-row in a jobs table that you have some consumer that runs a `select * from jobs where status = 'pending' limit 1;`. Then you're on the hook to handle the pg updates for dispatching and handling updates, job status, etc. You could even call that implementation pg-boss if it's not taken.
hyperman1 7 days ago [-]
The postgres COPY FROM PROGRAM will run external scripts, as the postgres user. Not necessarily a good architecture, of course. I did one day manage to fix a broken sshd with it by passing it su commands (rate that experience as 0 stars, would not recommend)
hoppp 8 days ago [-]
There is an HTTP extension for postgres, so it can trigger external serverless functions via http request
It works well with Supabase, I tried it, its decent but you should only use it for endpoints you trust because waiting for the request is blocking.
If you want the requests to be async you need to use pg_background extension with it
etchalon 9 days ago [-]
It's what I expected to be talked about exclusively in the article based on the title.
jbverschoor 8 days ago [-]
Cron/systemd/launchd is nice for machine-level tasks.
If you want application or platform level tasks, you’re better off scheduling a task on which ever job queue you run. That could also be pg.
That way you can have platform-wide unique tasks, probably better monitoring / tracing, etc.
mitjam 8 days ago [-]
Kubernetes CronJobs are nice and if you are on K8s, already, it’s also without extra infrastructure.
lukasb 9 days ago [-]
I can't be the only Next.js / neon user looking at this
wewewedxfgdf 9 days ago [-]
There's many ways to skin this cat. Personally I invested all my knowledge and focus into systemd timers. No doubt you have your own ways that make sense for you.
verdverm 9 days ago [-]
There's no systemd running in containers, so not an option in a lot of common scenarios
In other words, I want to disable all jobs for some time (for benchmarking) and then bring them back up.
Stop all active timers: ```bash sudo systemctl stop $(cat /tmp/active_timers.txt) ```
Later, restart the previously active timers: ```bash sudo systemctl start $(cat /tmp/active_timers.txt) ```
Some others:
* https://github.com/LaunchPlatform/bq
* https://github.com/cybertec-postgresql/pg_timetable
* https://github.com/pgmq/pgmq
* https://github.com/riverqueue/river
* https://github.com/oban-bg/oban
* https://github.com/pgadmin-org/pgagent
* https://github.com/citusdata/pg_cron
etc. There are plenty of options to choose from.
0: https://github.com/timgit/pg-boss
https://github.com/tktech/chancy
> As a rule of thumb, if you're processing less than 1000 jobs per day or your jobs are mostly lightweight operations (like sending emails or updating records), you can stick with this solution.
This seems... excessively low? Chancy is on the heavier side and happily does many millions of jobs per day. Postgres has no issue with such low throughput, even on resource constrained systems (think a $5 vps). Maybe they meant 1000 per second?
Chancy also looks pretty neat. Thanks for sharing!
Cron's name originates from Chronos, at least according to Wikipedia.
You don't need WASP for any of this, certainly not worth learning their custom DSL for it. Two of their points about how it makes it better are moot, setting queue names (one line of code) and type safety (you should be using TS already). I've not seen the value in their abstractions and indirection.
How does your library work in this regard? If my node server is down, will my scheduled tasks still execute? I notice you have a .start() method, what does that do? Is it polling periodically?
pg_cron is for pg specific cron tasks. You use pg_cron to truncate a table, compute pg views, values, aggregates, etc. Basically just running PG queries on a CRON schedule.
pg_cron itself won't run an external script for you. Like you can't do
you can use pg_cron to insert a job-row in a jobs table that you have some consumer that runs a `select * from jobs where status = 'pending' limit 1;`. Then you're on the hook to handle the pg updates for dispatching and handling updates, job status, etc. You could even call that implementation pg-boss if it's not taken.It works well with Supabase, I tried it, its decent but you should only use it for endpoints you trust because waiting for the request is blocking.
If you want the requests to be async you need to use pg_background extension with it
If you want application or platform level tasks, you’re better off scheduling a task on which ever job queue you run. That could also be pg.
That way you can have platform-wide unique tasks, probably better monitoring / tracing, etc.