On Tue, Nov 26, 2013 at 11:32 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > After fixing that bug, I'm getting a correctly-detected deadlock every now > and then with that test case.
We'll probably want to carefully consider how predictably/deterministically this occurs. > Hmm. That's because the trick I used to kill the just-inserted tuple > confuses a concurrent heap_lock_tuple call. It doesn't expect the tuple it's > locking to become invisible. Actually, doesn't your patch have the same bug? > If you're about to lock a tuple in ON DUPLICATE KEY LOCK FOR UPDATE, and the > transaction that inserted the duplicate row aborts just before the > heap_lock_tuple() call, I think you'd also see that error. Yes, that's true. It will occur much more frequently with your previous revision, but the V4 patch is also affected. >> To me this seems like a problem with the (potential) total lack of >> locking that your approach takes (inserting btree unique index tuples >> as in your patch is a form of value locking...sort of...it's a little >> hard to reason about as presented). Do you think this might be an >> inherent problem, or can you suggest a way to make your approach still >> work? > > > Just garden-variety bugs :-). Attached patch fixes both issues. Great. I'll let you know what I think. >> * Doesn't just work with one unique index. Naming a unique index >> directly in DML, or assuming that the PK is intended seems quite weak >> to me. > Totally agreed on that. Good. BTW, you keep forgetting to add "expected" output of the new isolation tests. -- 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
