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
