On Thu, Oct 13, 2016 at 2:32 PM, Peter Geoghegan <pg@xxxxxxx> wrote: > On Wed, Oct 12, 2016 at 6:06 PM, Thomas Munro > <thomas.munro@xxxxxxxxxxxxxxxx> wrote: >> But yeah, the existing code raises false positive serialization >> failures under SERIALIZABLE, and that's visible in the isolation test >> I posted: there is actually a serial order of those transactions with >> the same result. > > I was under the impression that false positives of this kind are > allowed by SSI. Why focus on this false positive scenario in > particular? Sure, they're allowed. Of course the ones caused by your own command are questionable because there is no concurrent transaction and retrying the transaction will never succeed, as discussed, but it seems we all agree on that. The question is just whether INSERT ... ON CONFLICT should generate more false positives than plain old INSERT. Two overlapping conflicting plain old INSERTs without any other entanglement to create a cycle will result in one succeeding and the other getting a UCV, as if one ran after the other with no overlap. It would be nice if the ON CONFLICT case used the same smarts to take the ON CONFLICT path, unless there is some theoretical problem I'm overlooking. Otherwise concurrency is reduced. I wonder if we should fix the same-command problem reported by the OP, and then study larger questions of ON CONFLICT/SERIALIZABLE interaction as a separate project. I may be imagining problems where there are none... -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general