Re: INSERT...ON DUPLICATE KEY IGNORE - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: INSERT...ON DUPLICATE KEY IGNORE
Date
Msg-id CAM3SWZSZWkdjwjKCki5YH-YZ2kr5+sO+St0h5cfY8bn+pARfeQ@mail.gmail.com
Whole thread Raw
In response to Re: INSERT...ON DUPLICATE KEY IGNORE  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: INSERT...ON DUPLICATE KEY IGNORE
List pgsql-hackers
On Wed, Sep 4, 2013 at 3:39 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> Sorry to be harsh here, but I don't think I need to do that. I've
> explained most of the reasons I see that that approach won't work out
> and so far I don't see those refuted. And to me those issues seem to be
> fatal for the approach. If you find a solution to the problems noted
> uppon - great. So far it seems neither Robert nor me see how that is
> possible, but that obviously doesn't mean it's impossible that you find
> a way.

It seems you've misunderstood. My position was that I don't think it's
terribly useful to have a discussion about approaches to value locking
without considering how that needs to fit in with row locking too. So
it makes sense as an immediate goal to introduce that into the patch.
Any scheme is going to be constrained by having to think about the
interplay with value locking and row locking going forward.

For example, in my scheme, I couldn't block on locking the row if that
meant that buffer locks would be held indefinitely. There are also
deadlock hazards there for either scheme that must be carefully
considered.

What possible objection could you have? Suppose it was the case that I
was dead set on using buffer locking like this, because I'm stubborn
or whatever. I've just made life harder for myself, while probably not
also putting the same degree of burden on alternative proposals. Maybe
I am stubborn, but I don't think I'm stubborn about the basic approach
taken in this particular patch. I've merely been pointing out, as I
feel is my role as a participant in the community's adversarial system
of reaching agreement, the problems that exist with your proposal, and
some inconsistencies in your objections to mine.

Obviously the basic approach will remain the most difficult and
probably controversial part of this. Even if I threw my hands up and
immediately accepted everything you said, that would still be true. We
need to get all of the constraints in place sooner rather than later.

> But why should I argue further until you proof me wrong (newer patch or
> explaining changed algorithms)?

I didn't ask you to. You shouldn't.

> If you don't think my arguments are
> valid, well, I've brought those up I see as relevant and that's
> it. Can't do much further.

Uh, I just said that I thought your arguments were totally valid. I
couldn't have been clearer about that. Actually, I'm pretty surprised
that you haven't been the one insisting that I add a row locking
component from quite early on for exactly these reasons.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: INSERT...ON DUPLICATE KEY IGNORE
Next
From: Andres Freund
Date:
Subject: Re: INSERT...ON DUPLICATE KEY IGNORE