Python client for pg_tasks
Клиент для pg_tasks.
Предоставляет классы Tasks и Worker для создания рабочих процессов.
Установка
pip install pg_tasks_python
Quickstart
Запустим расширение и создадим таблицу для задачи:
CRAETE EXTENSION pg_tasks;
CREATE TABLE tasks.do_something(
LIKE tasks.template
INCLUDING DEFAULTS
INCLUDING IDENTITY
INCLUDING INDEXES,
payload text
);
SELECT tasks.register('tasks', 'do_something');
Опишем модуль на python:
from pg_tasks import Task, Worker
import psycopg
class DoSomething(Task):
def __init__(self, conn_factory):
super().__init__()
self.conn_factory = conn_factory
def run(self, id, **kwargs):
# Представим себе, что здесь полезный код))
print('DO HARD WORK')
# Подтверждение выполнения задачи
conn = None
try:
conn = self.conn_factory()
self.finish(conn, task_id=id)
finally:
if conn is not None:
conn.close()
# Композит
do_something = DoSomething(
lambda: psycopg.connect('dbname=test'),
)
worker = Worker('dbname=test')
worker.add(do_something)
worker.run()
Task
Базовый класс для задач. Метод run должен быть переопределен, и содержать
в себе саму задачу. Этот метод будет вызван при получении задач из БД.
Метод run принимает строку из БД в виде **kwargs. Все столбцы, описанные
в соответствующей таблице, будут переданы в задачу.
После успешного завершения бизнес-логики задачу необходимо пометить
как завершенную методом .finish(), передав в него id задачи
и время начала задачи. В большинстве случаев достаточно передать created_at
из kwargs.
В случае, когда задачу выполнить невозможно, и нужно повторить ее позже
(например, задача должна обратиться к внешнему сервису,
который сейчас недоступен), нужно вызвать метод retry, передав в него
id задачи и, опционально, время, после которого задача должна быть выполнена.
В случае, когда задачу выполнить невозможно, нужно выполнить метод cancel,
передав в него id задачи. Такая задача не будет доступна для повторения
другим воркерам, пока не будет сброшена.
Метод reset используется для сброса задач, принимает id задачи. Нужен,
в основном, для ручного перезапуска задач при авариях.
Метод clean принимает дату и время, и вычищает все задачи, успешно
выполненные до указанной даты.
Все методы принимают первым обязательным аргументом подключение к БД, через которое задача будет работать с БД.
В случае, когда задача работает в транзакции, крайне рекомендуется после завершения бизнес-логики оперировать задачей (подтверждать, отменять и т.д.) в той же транзакции.
Также в методы finish, cancel, и retry можно передать комментарий
к задаче в поле comment в виде строки, комментарий будет сохранен в БД.
Метод acquire нужен для вызова из Worker, напрямую он не используется.
Worker
Worker имеет 3 метода - add, remove и run.
Метод add используется для добавления новых типов задач.
Вторым аргументом можно задать количество рабочих потоков, по умолчанию - 1.
Если воркер уже запущен, то потоки будут запущены сразу, если нет - запуск
будет отложен до запуска воркера.
Метод remove используется для остановки определенного типа задач.
Метод run запускает worker. Метод блокирующий,
содержит в себе бесконечный цикл.
Внутри run делает несколько вещей.
Для каждого типа задачи запускается один или несколько рабочих потоков. Каждый рабочий поток циклически запрашивает пачку задач и последовательно выполняет их. Если получена пустая пачка, значит, задач к выполнению сейчас нет, и рабочий поток встает на паузу в ожидании уведомления о новой задаче. Если уведомление не приходит в интервал, заданный в задаче, то рабочий поток начинает цикл заново.
Также Worker создает поток-слушатель. Слушатель получает уведомления в канале pg_tasks, и уведомляет рабочие потоки о них. Также слушатель регулярно пингует DB, когда уведомлений нет больше определенного времени.
Metadata
Release files for pg-tasks 0.0.4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| pg_tasks-0.0.4.tar.gz | 10.3 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| pg_tasks-0.0.4-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 18.8 kB
Release files / pg_tasks-0.0.4.tar.gz
| Download URL | pg_tasks-0.0.4.tar.gz |
|---|---|
| Size | 10.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
19da63e70c121fc29e9979cb113ac72cbac98d79a8fa22be0de97614fd4ae3a4
|
|
BLAKE2b-256 checksum How to use checksums |
fc5a931ade760bc3b4f0233138c6b9608c85b5f22373479b6653359d05d82b85
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 2, 2026.
Transparency logRelease files / pg_tasks-0.0.4-py3-none-any.whl
| Download URL | pg_tasks-0.0.4-py3-none-any.whl |
|---|---|
| Size | 8.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
0b07a58325048b1ab34f714a83f5734abe69811c8894f18def8d485c79e92a52
|
|
BLAKE2b-256 checksum How to use checksums |
a547be7814432862e022021edf48c5dc44a87d29915b7be771f4ce40f506f4d1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 2, 2026.
Transparency logSecurity for pg-tasks 0.0.4
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for pg_tasks-0.0.4.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 2, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.