Hey Manoj - you can use Postgres as a Celery result backend via SQLAlchemy, if that's what you're asking?

Correct, thanks for mentioning!

Python 3.11.6 and Celery 5.3.4

Can you share your code in a gist or something?

glad you managed to fix it!

Tom Huibregtse no worries! I can't see nothing wrong with your gist either. Let me know if you come across it again.

Tom Huibregtse hmm, I've just double checked, and this is what I'm trying: import inspect ... @app.task(name="sleep") def sleep(): print(inspect.getmodule(time.sleep)) time.sleep(0.5) When I run this task through a Celery worker with the --pool=gevent option, I see this in the output: 14:11:15 worker.1 | [2023-12-15 14:11:15,316: WARNING/MainProcess] <module 'gevent.hub' from '/opt/homebrew/lib/python3.11/site-packages/gevent/hub.py'> 14:11:15 worker.1 | [2023-12-15 14:11:15,829: INFO/MainProcess] Task sleep[3728dc0f-f208-4a7a-a2ca-bbd71367bc0d] succeeded in 0.5130529159214348s: None Which looks like time.sleep has been monkey patched. I've pasted a gist of how I run this here: https://gist.github.com/bstiel/a9c1951d28b01a99579c11ad76ded3d9 Do you mind sharing yours?

You're are right, Tom. It is a bit confusing but in the context of the gevent pool, time.sleep is the same as gevent.sleep. When you use the gevent pool, Celery calls gevent's monkey.patch_all() which in turn patches the time module. So even though it says time.sleep, it is actually gevent.sleep.

I see it like this: Kombu officially supports the filesystem, has unit tests for the filesystem transport and even recent commits. As Kombu is Celery's underlying messaging library, I think any transport option supported by Kombu is supported by Celery (and the Celery docs are a bit patchy anyway).