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

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

In response to

Responses

Browse pgsql-hackers by date

  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