Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} - Mailing list pgsql-hackers

On Fri, Sep 26, 2014 at 5:40 PM, Peter Geoghegan <pg@heroku.com> wrote:
> I will be frank. Everyone knows that the nbtree locking parts of this
> are never going to be committed over your objections. It cannot
> happen. And yet, I persist in proposing that we go that way. I may be
> stubborn, but I am not so stubborn that I'd jeopardize all the work
> I've put into this to save one aspect of it that no one really cares
> about anyway (even I only care about meeting my goals for user visible
> behavior [2]). I may actually come up with a better way to make what
> you outline work; then again, I may not. I have no idea, to be honest.
> It's pretty clear that I'm going to have a hard time getting your
> basic approach to value locking accepted without rethinking it a lot,
> though. Can you really say that you won't have serious misgivings
> about something like the "tuple->xmin = InvalidTransactionId"
> swapping, if I actually formally propose it? That's very invasive to a
> lot of places. And right now, I have no idea how we could do better.
>
> I really only want to get to where we have a design that's acceptable.
> In all sincerity, I may yet be convinced to go your way. It's possible
> that I've failed to fully understand your concerns. Is it really just
> about making INSERT ... ON CONFLICT IGNORE work with exclusion
> constraints (UPDATE clearly makes little sense)?

I'll be frank, too.  Heikki doesn't need to persuade you to go his
way, because everyone other than yourself who has looked at this
problem has come up with a design that looks like his.  That includes,
but is not limited to, every committer who has looked at this.  The
burden of proof is on you to convince everyone else that the promise
tuple approach is wrong, not on everyone else to convince you that
it's right.  This is a community, and it operates by consensus.  Your
opinion, no matter how strongly held in the face of opposition, is not
a consensus.

As far as finding an option that's better than clearing the xmin, the
point is not that we'd commit that design.  Well, we might, if
somebody does a careful audit of all the relevant code paths and makes
a convincing argument that it's safe.  But more likely, somebody will
go find some other bit space that can be used to do this.  The fact
that it's not immediately obvious to you (or Heikki) where to find
that bit-space is not a principled argument for changing the whole
design.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company