Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On 12/26/2013 01:27 AM, Peter Geoghegan wrote:
> On Wed, Dec 25, 2013 at 6:25 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> And yes, I still think that promise tuples might be a better solution
>> regardless of the issues you mentioned, but you know what? That doesn't
>> matter. Me thinking it's the better approach is primarily based on gut
>> feeling, and I clearly haven't voiced clear enough reasons to convince
>> you. So you going with your own, possibly more substantiated, gut
>> feeling is perfectly alright. Unless I go ahead and write a POC of my
>> own at least ;)
>
> My position is not based on a gut feeling. It is based on carefully
> considering the interactions of the constituent parts, plus the
> experience of actually building a working prototype.

I also carefully considered all that stuff, and reached a different 
conclusion. Plus I also actually built a working prototype (for some 
approximation of "working" - it's still a prototype).

>> Whoa? What? Not convincing everyone is far from it being a useless
>> discussion. Such an attitude sure is not the way to go to elicit more
>> feedback.
>> And it clearly gave you the feedback that most people regard holding
>> buffer locks across other nontrivial operations, in a potentially
>> unbounded number, as a fundamental problem.
>
> Uh, I knew that it was a problem all along. While I explored ways of
> ameliorating the problem, I specifically stated that we should discuss
> the subsystems interactions/design, which you were far too quick to
> dismiss. The overall design is far more pertinent than one specific
> mechanism. While I certainly welcome your participation, if you want
> to be an effective reviewer I suggest examining your own attitude.
> Everyone wants this feature.

Frankly I'm pissed off that you dismissed from the start the approach 
that seems much better to me. I gave you a couple of pointers very early 
on: look at the way we do exclusion constraints, and try to do something 
like promise tuples or killing an already-inserted tuple. You dismissed 
that, so I had to write that prototype myself. Even after that, you have 
spent zero effort to resolve the remaining issues with that approach, 
proclaiming that it's somehow fundamentally flawed and that locking 
index pages is obviously better. It's not. Sure, it still needs work, 
but the remaining issue isn't that difficult to resolve. Surely not any 
more complicated than what you did with heavy-weight locks on b-tree 
pages in your latest patch.

Now, enough with the venting. Back to drawing board, to figure out how 
best to fix the deadlock issue with the 
insert_on_dup-kill-on-conflict-2.patch. Please help me with that.

PS. In btreelock_insert_on_dup_v5.2013_12_28.patch, the language used in 
the additional text in README is quite difficult to read. Too many 
difficult sentences and constructs for a non-native English speaker like 
me. I had to look up "concomitantly" in a dictionary and I'm still not 
sure I understand that sentence :-).

- Heikki