Re: serializable anomaly - duplicate primary keys - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: serializable anomaly - duplicate primary keys
Date
Msg-id CAJ7c6TMJ1ChMgfyY+_pT4ncAC9tf7TO1c3wuErhg-aUHqF74Pg@mail.gmail.com
Whole thread
In response to Re: serializable anomaly - duplicate primary keys  (Aleksander Alekseev <aleksander@tigerdata.com>)
List pgsql-hackers
Hi,

> The root cause is that unique checks use a dirty snapshot. They can
> decide a key is unused because of a deletion the transaction cannot
> see. The fix might be to ask our own snapshot the same question, and
> fail if it still sees the key in use. I don't think this will require
> an ABI change.

I prepared a PoC patch that shows how this could be archived. Also it
includes regression tests for everything discussed above.

One drawback I discovered is that the patch introduces a
false-positive conflict detection that causes the existing
partition-key-update-3.spec to fail. I'm not 100% certain what to do
about it. Given the fact that SSI generally has false-positives, maybe
we should just rewrite the test? This seems to be better compared to
what we currently have and personally I don't have better proposals at
the moment.

Thoughts?

-- 
Best regards,
Aleksander Alekseev

Attachment

pgsql-hackers by date:

Previous
From: Greg Burd
Date:
Subject: Re: Let an ordering index scan hand its ORDER BY value to the target list
Next
From: Jacob Champion
Date:
Subject: Re: Adding init-po and update-po targets to the meson build system