Re: SSI bug?

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