On 2015-02-16 10:00:24 +0200, Heikki Linnakangas wrote: > On 02/16/2015 02:44 AM, Peter Geoghegan wrote: > >>Are we happy with acquiring the SpeculativeInsertLock heavy-weight lock for > >>every insertion? That seems bad for performance reasons. Also, are we happy > >>with adding the new fields to the proc array? Another alternative that was > >>discussed was storing the speculative insertion token on the heap tuple > >>itself. (See > >>http://www.postgresql.org/message-id/52d00d2d.6030...@vmware.com) > > > >Whatever works, really. I can't say that the performance implications > >of acquiring that hwlock are at the forefront of my mind. I never > >found that to be a big problem on an 8 core box, relative to vanilla > >INSERTs, FWIW - lock contention is not normal, and may be where any > >heavweight lock costs would really be encountered. > > Oh, cool. I guess the fast-path in lmgr.c kicks ass, then :-).
I don't think it actually uses the fast path, does it? IIRC that's restricted to LOCKTAG_RELATION when done via LockAcquireExtended + open coded for the VirtualXactLock table. I'm not super worried atm either. Worth checking, but probably not worth obsessing over. > >Besides, why should one transaction be entitled to insert a > >conflicting value tuple just because a still running transaction > >deleted it (having also inserted the tuple itself)? Didn't one > >prototype version of value locking #2 have that as a bug [1]? In fact, > >originally, didn't the "xmin set to invalid" thing come immediately > >from realizing that that wasn't workable? > > Ah, right. So the problem was that some code might assume that if you insert > a row, delete it in the same transaction, and then insert the same value > again, the 2nd insertion will always succeed because the previous insertion > effectively acquired a value-lock on the key. > > Ok, so we can't unconditionally always ignore tuples with xmin==xmax. We > would need an infomask bit to indicate super-deletion, and only ignore it if > the bit is set. > > I'm starting to think that we should bite the bullet and consume an infomask > bit for this. The infomask bits are a scarce resource, but we should use > them when it makes sense. It would be good for forensic purposes too, to > leave a trace that a super-deletion happened. Well, we IIRC don't have any left right now. We could reuse MOVED_IN|MOVED_OUT, as that never was set in the past. But it'd essentially use two infomask bits forever... > >Jim Nasby said something about setting the HEAP_XMIN_INVALID hint bit. > >Maybe he is right...if that can be made to be reliable (always > >WAL-logged), it could be marginally better than setting xmin to > >invalidTransactionId. > > I'm not a big fan of that. The xmin-invalid bit is currently always just a > hint. We already rely on XMIN_INVALID being set correctly for freezing. C.f. HeapTupleHeaderXminFrozen, HeapTupleHeaderXminInvalid, et al. So it'd not necessarily end up being that bad. And the super deletion could easily just set it in the course of it's WAL logging. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
