From: | Kannan Goundan <kannan(at)cakoose(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Will using subtransactions will come back to bite me? |
Date: | 2022-03-28 08:49:54 |
Message-ID: | CAM7aVoUYax62u8A49WLjOLOKqg8mLE-LzDThBZbC8=n9QQeyAw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I'm a backend web developer working on a pretty typical Postgres-backed web
application. Each HTTP request is handled within a "SERIALIZABLE"
transaction.
For some requests, we need to perform a sub-operation (which might fail)
and record the success/failure in the DB. Subtransactions offer a simple
way to do that -- the overall request is still wrapped in a transaction,
and the sub-operation would be wrapped a subtransaction.
But a few things I've read online have made me wary of subtransactions:
1.
https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful
2.
https://about.gitlab.com/blog/2021/09/29/why-we-spent-the-last-month-eliminating-postgresql-subtransactions/
3.
https://buttondown.email/nelhage/archive/notes-on-some-postgresql-implementation-details/
But those articles seem to describe a use case that's more demanding than
mine. They talk about deeply-nested subtransactions, whereas I will only
have 1 (maybe 2) levels of nesting within the top-level transaction.
I'd appreciate any pointers on how to determine whether a particular use of
subtransactions will run into the issues described in the linked articles.
(I'm currently using Postgres 13.5 on GCP. Upgrading would require some
effort, but I'm open to it!)
From | Date | Subject | |
---|---|---|---|
Next Message | Philippe Doussot | 2022-03-28 09:42:22 | Re: Leading comments and client applications |
Previous Message | Alvaro Herrera | 2022-03-28 08:13:25 | Re: support for DIN SPEC 91379 encoding |