Cron's name originates from Chronos, at least according to Wikipedia.
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.
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!
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.
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.
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?
xnx•8mo ago
etchalon•8mo ago
eddythompson80•8mo ago
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.hoppp•8mo ago
cpursley•8mo ago
hoppp•8mo ago
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
hyperman1•8mo ago