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
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Список | 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 по дате отправления: