Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
От | Robert Haas |
---|---|
Тема | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Дата | |
Msg-id | CA+TgmoZ+Vk54z8K_yE0ufDSB8uhcuUh_Ri=1Z+CS0DiP4hdoBg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
|
Список | pgsql-hackers |
On Tue, Dec 31, 2013 at 4:12 AM, Peter Geoghegan <pg@heroku.com> wrote: > On Tue, Dec 31, 2013 at 12:52 AM, Heikki Linnakangas > <hlinnakangas@vmware.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? Yeah, it seems like PromiseTupleInsertionLockAcquire should be locking the tuple, rather than the XID. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: