From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com> |
Subject: | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Date: | 2013-09-14 08:57:43 |
Message-ID: | CAM-w4HN_0ijXLp2sN0sOzdQbNzEx-bFEJW0D9HSXkwr3wWQeag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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....
It seems to me that the nature of the problem is that there will
unavoidably be a nexus between the 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.
I'm imagining a function that takes two target heap buffers and a btree
key. It would descend the btree and holding the leaf page lock do a
try_lock on the heap pages. If it fails to get the locks then it releases
whatever it got and returns for the heap update to find new pages and try
again.
This still leaves the potential problem with page splits and I assume it
would still be tricky to call it without unsatisfactorily mixing executor
and btree code. But that's as far as I got.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2013-09-14 09:26:16 | Re: Proposal: PL/PgSQL strict_mode |
Previous Message | Robert Haas | 2013-09-14 07:22:42 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |