Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
От | Andres Freund |
---|---|
Тема | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Дата | |
Msg-id | 20131224120901.GD26564@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
|
Список | pgsql-hackers |
On 2013-12-23 14:59:31 -0800, Peter Geoghegan wrote: > On Mon, Dec 23, 2013 at 7:49 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > I don't think this is a project to rush through. We've lived without > > MERGE/UPSERT for several years now, and we can live without it for > > another release cycle while we try to reach agreement on the way > > forward. Agreed, but I really think it's one of the biggest weaknesses of postgres at this point. > > I can tell that you're convinced you know the right way > > forward here, and you may be right, but I don't think you've convinced > > everyone else - maybe not even anyone else. > That may be. Attention from reviewers has been in relatively short > supply. Not that that isn't always true. I don't really see the lack of review as being crucial at this point. At least I have quite some doubts about the approach you've chosen and I have voiced it - so have others. Whether yours is workable seems to hinge entirely on whether you can build a scalable, maintainable value-locking scheme. Besides some thoughts about using slru.c for it I haven't seen much about the design of that part - might just have missed it though. Personally I can't ad-lib a design for it, but I haven't though about it too much. I don't think there's too much reviewers can do before you've provided a POC implementation of real value locking. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: