On Thu, Jan 2, 2014 at 8:08 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: >> Yeah, it seems like PromiseTupleInsertionLockAcquire should be locking >> the tuple, rather than the XID. > > Well, that would be ideal, because we already have tuple locks. It would be > nice to use the same concept for this. It's a bit tricky, however. I guess > the most straightforward way to do it would be to grab a heavy-weight lock > after you've inserted the tuple, but before releasing the buffer lock. I > don't immediately see a problem with that, although it's a bit scary to > acquire a heavy-weight lock while holding a buffer lock.
That's a really big modularity violation. Everything after RelationPutHeapTuple() but before the buffer unlock in heap_insert() is currently critical section. I'm not saying that it can't be done, but it certainly is scary. We also have heavyweight page locks, currently used by hash indexes. That approach does not require us to contort the row locking code, and certainly does not require us to acquire heavyweight locks with buffer locks already held. I could understand your initial disinclination to doing things this way, particularly when the unprincipled deadlocking problem was not well understood, but I think that this must tip the balance in favor of the approach I advocate. What I've done with heavyweight locks is a modest, localized, logical expansion on the existing mechanism, that is easy to reason about, with room for further optimization in the future, that still has reasonable performance characteristics today, including I believe better worst-case latency. Heavyweight locks on btree pages are very well precedented, if you look beyond Postgres. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
