On Tue, Dec 31, 2013 at 4:12 AM, Peter Geoghegan <p...@heroku.com> wrote: > On Tue, Dec 31, 2013 at 12:52 AM, Heikki Linnakangas > <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers