Re: SSI bug?

Поиск
Список
Период
Сортировка
От yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
Тема Re: SSI bug?
Дата
Msg-id 20110407020210.D851019CF0A@mail.netbsd.org
обсуждение исходный текст
Ответ на Re: SSI bug?  (Dan Ports <drkp@csail.mit.edu>)
Ответы Re: SSI bug?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: SSI bug?  (yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi))
Список pgsql-hackers
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/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: too many dotted names
Следующее
От: Alastair Turner
Дата:
Сообщение: Re: superusers are members of all roles?