On Thu, 24 Mar 2022 at 11:01, Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Thu, Mar 24, 2022 at 11:44 PM Simon Riggs > <simon.ri...@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/
partial_patch_for_read-write-unique-4_serialization_error.v1.patch
Description: Binary data
isotest_read-write-unique-5.v1.patch
Description: Binary data
