Comments 5
Вы изобретаете dbms_scheduler из Oracle. Не подумайте, ничего плохого в этом не вижу, даже наоборот. Если интересно - можете подсмотреть что там есть хорошего для вас.
Например - объединение заданий в классы: "эти 10 - закрытие дня", "эти 20 - отчетность" и так далее.
Выстаивание последовательности заданий: "эта задача стартует по завершению вот той" - выстаивается цепочка логически взаимосвязанных заданий и не нужно до минут высчитывать время выполнения каждой из них.
Приоритезация и окна выполнения: "с 23:00 до 6:00" должны быть выполнены эти 200 заданий, их приоритет такой-то.
Ну и так далее. Удачи.
кажется тут advisory lock был бы более производительным вариантом по сравнению с таблицей heartbeat
воркер раз в N секунд “пингует” себя в БД
Если вместо (или кроме) абстрактного worker_id фиксировать в таблице pg_backend_pid(), то никакого heartbeat не требуется. Достаточно по pg_stat_activity проверять наличие pid и сравнивать backend_start с временем последней модификации задачи. Если backend_start больше времени модификации задачи или такого pid нет в pg_stat_activity, то процесс умер и блокировки нет.
Очередь задач на Postgres: SKIP LOCKED + lease/heartbeat + backpressure (практический опыт)