On Thu, 24 Mar 2022 at 14:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Simon Riggs <simon.riggs@enterprisedb.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/
