Re: SERIALIZABLE and INSERTs with multiple VALUES

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Kevin Grittner <kgrittn(at)gmail(dot)com>, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Jason Dusek <jason(dot)dusek(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: SERIALIZABLE and INSERTs with multiple VALUES
Date: 2016-10-13 03:46:30
Message-ID: CAEepm=2kj5C=5b+PDbORUngzVf56yrhXUdrOoP5d1+JS-RxBiA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Oct 13, 2016 at 2:32 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Wed, Oct 12, 2016 at 6:06 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andreas Joseph Krogh 2016-10-13 08:14:08 pg_upgrade not able to cope with pg_largeobject being in a different tablespace
Previous Message avi Singh 2016-10-13 02:16:06 Re: MultiXact member wraparound protections are disabled