On 01.03.2011 02:03, Dan Ports wrote:
> An updated patch to address this issue is attached. It fixes a couple
> issues related to use of the backend-local lock table hint:
>
> - CheckSingleTargetForConflictsIn now correctly handles the case
> where a lock that's being held is not reflected in the local lock
> table. This fixes the assertion failure reported in this thread.
>
> - PredicateLockPageCombine now retains locks for the page that is
> being removed, rather than removing them. This prevents a
> potentially dangerous false-positive inconsistency where the local
> lock table believes that a lock is held, but it is actually not.
>
> - add some more comments documenting the times when the local lock
> table can be inconsistent with reality, as reflected in the shared
> memory table.
>
> This patch also incorporates Kevin's changes to copy locks when
> creating a new version of a tuple rather than trying to maintain a
> linkage between different versions. So this is a patch that should
> apply against HEAD and addresses all outstanding SSI bugs known to
> Kevin or myself.
Thanks, committed with minor changes.
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 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.
Was there test cases for any of the issues fixed by this patch that we
should add to the suite?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com