Re: INSERT...ON DUPLICATE KEY IGNORE

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: INSERT...ON DUPLICATE KEY IGNORE
Дата
Msg-id CAM3SWZSZWkdjwjKCki5YH-YZ2kr5+sO+St0h5cfY8bn+pARfeQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: INSERT...ON DUPLICATE KEY IGNORE  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: INSERT...ON DUPLICATE KEY IGNORE  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Wed, Sep 4, 2013 at 3:39 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> Sorry to be harsh here, but I don't think I need to do that. I've
> explained most of the reasons I see that that approach won't work out
> and so far I don't see those refuted. And to me those issues seem to be
> fatal for the approach. If you find a solution to the problems noted
> uppon - great. So far it seems neither Robert nor me see how that is
> possible, but that obviously doesn't mean it's impossible that you find
> a way.

It seems you've misunderstood. My position was that I don't think it's
terribly useful to have a discussion about approaches to value locking
without considering how that needs to fit in with row locking too. So
it makes sense as an immediate goal to introduce that into the patch.
Any scheme is going to be constrained by having to think about the
interplay with value locking and row locking going forward.

For example, in my scheme, I couldn't block on locking the row if that
meant that buffer locks would be held indefinitely. There are also
deadlock hazards there for either scheme that must be carefully
considered.

What possible objection could you have? Suppose it was the case that I
was dead set on using buffer locking like this, because I'm stubborn
or whatever. I've just made life harder for myself, while probably not
also putting the same degree of burden on alternative proposals. Maybe
I am stubborn, but I don't think I'm stubborn about the basic approach
taken in this particular patch. I've merely been pointing out, as I
feel is my role as a participant in the community's adversarial system
of reaching agreement, the problems that exist with your proposal, and
some inconsistencies in your objections to mine.

Obviously the basic approach will remain the most difficult and
probably controversial part of this. Even if I threw my hands up and
immediately accepted everything you said, that would still be true. We
need to get all of the constraints in place sooner rather than later.

> But why should I argue further until you proof me wrong (newer patch or
> explaining changed algorithms)?

I didn't ask you to. You shouldn't.

> If you don't think my arguments are
> valid, well, I've brought those up I see as relevant and that's
> it. Can't do much further.

Uh, I just said that I thought your arguments were totally valid. I
couldn't have been clearer about that. Actually, I'm pretty surprised
that you haven't been the one insisting that I add a row locking
component from quite early on for exactly these reasons.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: INSERT...ON DUPLICATE KEY IGNORE
Следующее
От: Andres Freund
Дата:
Сообщение: Re: INSERT...ON DUPLICATE KEY IGNORE