Re: Documenting when to retry on serialization failure
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Simon Riggs <simon.riggs@enterprisedb.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-03-24T14:05:48Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Thu, Mar 24, 2022 at 11:44 PM Simon Riggs > <simon.riggs@enterprisedb.com> wrote: >> The unique violation thing is worryingly general. Do we know enough to >> say that this is thought to occur only with a) multiple unique >> constraints, b) exclusion constraints? > I'm aware of 3 cases. The two you mentioned, which I think we can fix > (as described in the threads I posted upthread), and then there is a > third case that I'm still confused about, in the last line of > read-write-unique-4.spec. That test is modeling the case where the application does an INSERT with values based on some data it read earlier. There is no way for the server to know that there's any connection, so I think if you try to throw a serialization error rather than a uniqueness error, you're basically lying to the client by claiming something you do not know to be true. And the lie is not without consequences: if the application believes it, it might iterate forever vainly trying to commit a transaction that will never succeed. regards, tom lane
Commits
-
Doc: add some documentation about serialization failure handling.
- 0adb3dc68bfb 15.0 landed
-
Detect SSI conflicts before reporting constraint violations
- fcff8a575198 9.6.0 cited