On Wed, Sep 4, 2013 at 5:08 PM, Andres Freund <and...@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 adapt it 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
