On Thu, 24 Mar 2022 at 11:01, Thomas Munro <thomas.munro@gmail.com> wrote:
>
> 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.
I don't see any confusion - it is clearly a serialization error. What
is more, I see this as a confusing bug that we should fix.
If we were updating the row rather than inserting it, we would get
"ERROR: could not serialize access due to concurrent update", as
documented. The type of command shouldn't affect whether it is a
serialization error or not. (Attached patch proves it does throw
serializable error for UPDATE).
Solving this requires us to alter the Index API to pass down a
snapshot to allow us to test whether the concurrent insert is visible
or not. The test is shown in the attached patch, but this doesn't
attempt the major task of tweaking the APIs to allow this check to be
made.
--
Simon Riggs http://www.EnterpriseDB.com/
