Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Дата
Msg-id CAM-w4HN_0ijXLp2sN0sOzdQbNzEx-bFEJW0D9HSXkwr3wWQeag@mail.gmail.com
обсуждение исходный текст
Ответ на Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Andres Freund <andres@2ndquadrant.com>)
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
<p dir="ltr">I haven't read the patch and the btree code is an area I really don't know, so take this for what it's
worth....<br/><p dir="ltr">It seems to me that the nature of the problem is that there will unavoidably be a nexus
betweenthe two parts of the code here. We can try to isolate it as much as possible but we're going to need a bit of a
compromise.<pdir="ltr">I'm imagining a function that takes two target heap buffers and a btree key. It would descend
thebtree and holding the leaf page lock do a try_lock on the heap pages. If it fails to get the locks then it releases
whateverit got and returns for the heap update to find new pages and try again.<p dir="ltr">This still leaves the
potentialproblem with page splits and I assume it would still be tricky to call it without unsatisfactorily mixing
executorand btree code. But that's as far as I got. <p dir="ltr">-- <br /> greg 

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: Proposal: PL/PgSQL strict_mode