On 12/26/2013 01:27 AM, Peter Geoghegan wrote:
On Wed, Dec 25, 2013 at 6:25 AM, Andres Freund <and...@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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to