From: | yamt(at)mwd(dot)biglobe(dot)ne(dot)jp (YAMAMOTO Takashi) |
---|---|
To: | drkp(at)csail(dot)mit(dot)edu |
Cc: | pgsql-hackers(at)postgresql(dot)org, Kevin(dot)Grittner(at)wicourts(dot)gov, heikki(dot)linnakangas(at)enterprisedb(dot)com |
Subject: | Re: SSI bug? |
Date: | 2011-04-07 02:02:10 |
Message-ID: | 20110407020210.D851019CF0A@mail.netbsd.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-04-07 03:52:16 | Re: getting to beta |
Previous Message | Tatsuo Ishii | 2011-04-07 01:34:16 | Re: GSoC Proposal - Caching query results in pgpool-II |