| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
| Date: | 2013-12-31 09:12:02 |
| Message-ID: | CAM3SWZS3c511sH-Net5Gs8i+2i-ehxV63dYe-ax4tN68U9B8Hg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Dec 31, 2013 at 12:52 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> 1. PromiseTupleInsertionLockAcquire(<my xid>)
> 2. Insert heap tuple
> 3. Insert index tuples
> 4. Check if conflict happened. Kill the already-inserted tuple on conflict.
> 5. PromiseTupleInsertionLockRelease(<my xid>)
>
> IOW, the only change to the current patch is that you acquire the new kind
> of lock before starting the insertion, and you release it after you've
> killed the tuple, or you know you're not going to kill it.
Where does row locking fit in there? - you may need to retry when that
part is incorporated, of course. What if you have multiple promise
tuples from a contended attempt to insert a single slot, or multiple
broken promise tuples across multiple slots or even multiple commands
in the same xact?
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christian Kruse | 2013-12-31 09:12:44 | Patch: show relation and tuple infos of a lock to acquire |
| Previous Message | Heikki Linnakangas | 2013-12-31 08:52:08 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |