Re: Documenting when to retry on serialization failure

On Thu, 24 Mar 2022 at 14:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> writes:
> > OK, I see what you mean. There are 2 types of transaction, one that
> > reads inside the transaction, one that decides what value to use some
> > other way.
>
> > So now we have 2 cases, both of which generate uniqueness violations,
> > but only one of which might succeed if retried. The patch does cover
> > this, I guess, by saying be careful, but I would be happier if we can
> > also add
>
> > "this is thought to occur only with multiple unique constraints and/or
> > an exclusion constraints"
>
> Um, what's that got to do with it? The example in
> read-write-unique-4.spec involves only a single pkey constraint.

Yes, but as you explained, its not actually a serializable case, it
just looks a bit like one.

That means we are not currently aware of any case where the situation
is serializable but the error message is uniqueness violation, unless
we have 2 or more unique constraints and/or an exclusion constraint.

> We could add something trying to explain that if the application inserts a
> value into a constrained column based on data it read earlier, then any
> resulting constraint violation might be effectively a serialization
> failure.

We could do that as well.

--
Simon Riggs http://www.EnterpriseDB.com/