Kai Schlamp

It's also important to note that if connections remain open for too long without being used, PostgreSQL may close them, and the next time you attempt to use that closed...

Finding a general solution could be challenging because connections are thread-local, making it difficult to close connections from a different thread. The asynchronous tasks run in the main thread, while...

Unfortunately, I don't think that this will work. As mentioned, sync tasks [run in their own thread](https://github.com/procrastinate-org/procrastinate/blob/e1453ddb29b20cec6104e789cab1fc176ece591e/procrastinate/worker.py#L248). Your `close_old_connections` only closes the connections in the main thread of the worker...

@jakajancar I can't say much about the memory leak, but according to @Xowap it seems to be related to the unclosed Django database connections. We can't do anything meaningful about...

> My question is whether, if I am running Procrastinate with concurrency=1 and only sync tasks, are those guaranteed by Procrastinate to execute on the same thread? No, since we...

Hi @LucasRoesler. You are correct in your assumptions. There is no automatic cancellation of jobs when a task or periodic task is removed. But it should be easy to write...

Hi @saro2-a. I think we only renamed `timeout` to `fetch_job_polling_interval` (see https://github.com/procrastinate-org/procrastinate/releases/tag/3.0.0b1), and `wait` was also a `boolean` in v2. But I wonder if it would make more sense to...

> Yep, `timeout` was something else entirely. So, is our release note wrong here? ("The `timeout` worker option was renamed to fetch_job_polling_interval to better reflect its purpose.) > I think...

> > This seems, nice, I'm wondering if you can share a bit on what led you to create a new function `procrastinate_retry_failed_job_v1` rather than adapting `procrastinate_retry_job_v1`. I'm not saying...