Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > IMHO it would be better to remove xmin from the lock key, and vacuum > away the old predicate locks when the corresponding tuple is vacuumed. > The xmin field is only required to handle the case that a tuple is > vacuumed, and a new unrelated tuple is inserted to the same slot. > Removing the lock when the tuple is removed fixes that. > > In fact, I cannot even come up with a situation where you would have a > problem if we just removed xmin from the key, even if we didn't vacuum > away old locks. I don't think the old lock can conflict with anything > that would see the new tuple that gets inserted in the same slot. I have > a feeling that you could probably prove that if you stare long enough at > the diagram of a dangerous structure and the properties required for a > conflict.
You are the one who suggested adding xmin to the key: http://www.postgresql.org/message-id/4d5a36fc.6010...@enterprisedb.com I will review that thread in light of your recent comments, but the fact is that xmin was not originally in the lock key, testing uncovered bugs, and adding xmin fixed those bugs. I know I tried some other approach first, which turned out to be complex and quite messy -- it may have been similar to what you are proposing now. It seems to me that a change such as you are now suggesting is likely to be too invasive to back-patch. Do you agree that it would make sense to apply the patch I have proposed, back to 9.1, and then consider any alternative as 9.4 material? -- Kevin Grittner EDB: 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
