Re: SSI bug?

hi,

> I think I see what is going on now. We are sometimes failing to set the
> commitSeqNo correctly on the lock. In particular, if a lock assigned to
> OldCommittedSxact is marked with InvalidSerCommitNo, it will never be
> cleared.
>
> The attached patch corrects this:
> TransferPredicateLocksToNewTarget should initialize a new lock
> entry's commitSeqNo to that of the old one being transferred, or take
> the minimum commitSeqNo if it is merging two lock entries.
>
> Also, CreatePredicateLock should initialize commitSeqNo for to
> InvalidSerCommitSeqNo instead of to 0. (I don't think using 0 would
> actually affect anything, but we should be consistent.)
>
> I also added a couple of assertions I used to track this down: a
> lock's commitSeqNo should never be zero, and it should be
> InvalidSerCommitSeqNo if and only if the lock is not held by
> OldCommittedSxact.
>
> Takashi, does this patch fix your problem with leaked SIReadLocks?

i'm currently running bf6848bc8c82e82f857d48185554bc3e6dcf1013 with this
patch applied. i haven't seen the symptom yet. i'll keep it running for
a while.

btw, i've noticed the following message in the server log. is it normal?

LOG: could not truncate directory "pg_serial": apparent wraparound

YAMAMOTO Takashi

>
> Dan
>
>
> --
> Dan R. K. Ports MIT CSAIL http://drkp.net/