Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE - Mailing list pgsql-hackers

From Greg Stark
Subject Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Date
Msg-id CAM-w4HN_0ijXLp2sN0sOzdQbNzEx-bFEJW0D9HSXkwr3wWQeag@mail.gmail.com
Whole thread Raw
In response to Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Next
From: Marko Tiikkaja
Date:
Subject: Re: Proposal: PL/PgSQL strict_mode