On Thu, Jan 2, 2014 at 11:08 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > On 01/02/2014 02:53 PM, Robert Haas wrote: >> 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? > > You can only have one speculative insertion in progress at a time. After > you've done all the index insertions and checked that you really didn't > conflict with anyone, you're not going to go back and kill the tuple > anymore. After that point, the insertion is not speculation anymore.
Yeah... but how does someone examining the tuple know that? We need to avoid having them block on the promise-tuple insertion lock if we've reacquired it meanwhile for a new speculative insertion. -- 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
