From 11a71b403e0296915c3d29c0b551a32f38600c44 Mon Sep 17 00:00:00 2001 From: Mitar Date: Sun, 7 Nov 2021 03:11:44 -0800 Subject: [PATCH 1/2] Cross-linking. --- content/articles/postgres-queues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/articles/postgres-queues.md b/content/articles/postgres-queues.md index 8e0a4139f..9f21cee10 100644 --- a/content/articles/postgres-queues.md +++ b/content/articles/postgres-queues.md @@ -19,7 +19,7 @@ The figure below shows a simulation of the effect. With a relatively high rate o Your first question may be: why put a job queue in Postgres at all? The answer is that although it may be far from the use case that databases are designed for, storing jobs in a database allows a program to take advantage of its transactional consistency; when an operation fails and rolls back, an injected job rolls back with it. Postgres transactional isolation also keeps jobs invisible to workers until their transactions commit and are ready to be worked. -Without that transactional consistency, having jobs that are worked before the request that enqueued them is fully committed is a common problem. [See the Sidekiq FAQ](https://github.com/mperham/sidekiq/wiki/FAQ#why-am-i-seeing-a-lot-of-cant-find-modelname-with-id12345-errors-with-sidekiq) on this subject for example. +Without that transactional consistency, having jobs that are worked before the request that enqueued them is fully committed is a common problem. [See the Sidekiq FAQ](https://github.com/mperham/sidekiq/wiki/FAQ#why-am-i-seeing-a-lot-of-cant-find-modelname-with-id12345-errors-with-sidekiq) and [this post](https://brandur.org/job-drain) on this subject for example. As we'll see below, there are very good reasons not to use your database as a job queue, but by following a few key best practices, a program can go pretty far using this pattern. From f217c06b3b428a6e4903e882e07eec45a11932a5 Mon Sep 17 00:00:00 2001 From: Mitar Date: Sun, 7 Nov 2021 11:48:53 -0800 Subject: [PATCH 2/2] Update content/articles/postgres-queues.md Co-authored-by: Brandur Leach --- content/articles/postgres-queues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/articles/postgres-queues.md b/content/articles/postgres-queues.md index 9f21cee10..0dc773d95 100644 --- a/content/articles/postgres-queues.md +++ b/content/articles/postgres-queues.md @@ -19,7 +19,7 @@ The figure below shows a simulation of the effect. With a relatively high rate o Your first question may be: why put a job queue in Postgres at all? The answer is that although it may be far from the use case that databases are designed for, storing jobs in a database allows a program to take advantage of its transactional consistency; when an operation fails and rolls back, an injected job rolls back with it. Postgres transactional isolation also keeps jobs invisible to workers until their transactions commit and are ready to be worked. -Without that transactional consistency, having jobs that are worked before the request that enqueued them is fully committed is a common problem. [See the Sidekiq FAQ](https://github.com/mperham/sidekiq/wiki/FAQ#why-am-i-seeing-a-lot-of-cant-find-modelname-with-id12345-errors-with-sidekiq) and [this post](https://brandur.org/job-drain) on this subject for example. +Without that transactional consistency, having jobs that are worked before the request that enqueued them is fully committed is a common problem. [See the Sidekiq FAQ](https://github.com/mperham/sidekiq/wiki/FAQ#why-am-i-seeing-a-lot-of-cant-find-modelname-with-id12345-errors-with-sidekiq) and [transactionally staged job drains](https://brandur.org/job-drain) on this subject. As we'll see below, there are very good reasons not to use your database as a job queue, but by following a few key best practices, a program can go pretty far using this pattern.