Re: Documenting when to retry on serialization failure - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Documenting when to retry on serialization failure
Date
Msg-id 2963837.1648130748@sss.pgh.pa.us
Whole thread Raw
In response to Re: Documenting when to retry on serialization failure  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Documenting when to retry on serialization failure  (Simon Riggs <simon.riggs@enterprisedb.com>)
List 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: multithreaded zstd backup compression for client and server
Next
From: Tom Lane
Date:
Subject: Re: Remove an unnecessary errmsg_plural in dependency.c