Re: SSI bug?

hi,

> 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.

i haven't seen the symptom since them. so i guess it was fixed by
your patch. thanks!

YAMAMOTO Takashi

>
> 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/
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers