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

Reply via email to