On Wed, Sep 4, 2013 at 5:08 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> I don't want "my" idea to win, I want a idea to win.
I know. I want the same thing.
> You're the patch author here whose plans are laid open to be scrutinized ;). If you think my idea has merit, use and
adaptit to reality. If not, find another, better, solution.
Sure.
> Even if our path to that goal is confrontational at times, the goal is to find a good solution, not the argument
itself.
Agreed.
> I haven't argued about INSERT ... DUPLICATE LOCK because the page locking scheme doesn't seem to work out for plain
DUPLICATE.No need to think/argue about the fancier version in that case.
I see where you're coming from, but my point is precisely that adding
a row locking component *isn't* fancier. I've come to realize that
it's an integral part of the patch, and that my previous omission of
row locking - and the subsequent defence of that decision I made in
passing - was ridiculous. In a world where IGNORE/not locking is a
feature we support, it can only exist as an adjunct to ON DUPLICATE
KEY LOCK - certainly not the other way around.
The tail cannot be allowed to wag the dog.
In posting the patch with a row locking component, I'll only be asking
you to consider that aspect separately. You may find that seeing the
problems I encounter and how I handle them will make you (or others)
re-assess your thoughts on value locking in a direction that nobody
expects right now. Equally, I myself may reassess things.
Now, I don't guarantee that that's the case, but it certainly seems
very possible. And so even if I were to concede right now that the
buffer locking approach is not workable, I feel it would be a little
premature to seriously get down to talking about the alternatives in
detail.
--
Peter Geoghegan