Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > committed with minor changes. Thanks! > The ordering of the fields in PREDICATELOCKTAG was bizarre, so I > just expanded the offsetnumber fields to an uint32, instead of > having the padding field. I think that's a lot more readable. I can understand that, but I wonder if we shouldn't have a comment mentioning that the offsetnumber field is larger than needed, in case someone later needs to add another 16 bit field for some reason, or we go to a hash function without the same quirks. > I also added an optimization in PredicateLockTupleRowVersionLink() > to not try to transfer the page locks, if the new tuple is on the > same page as the old one. That's very cheap to check, and it's > very common for an update to stay within a page. Thanks. I had it in mind to do that, but lost track of it. Definitely worth doing. > Was there test cases for any of the issues fixed by this patch > that we should add to the suite? No, but I'm still intending to look at that some more. It makes me nervous to have an area which would be pretty easy for someone to break without any tests to catch such breakage. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
