| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Dan Ports <drkp(at)csail(dot)mit(dot)edu> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, YAMAMOTO Takashi <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Subject: | Re: SSI bug? |
| Date: | 2011-04-11 11:01:22 |
| Message-ID: | 4DA2DF82.1090407@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 03.04.2011 09:16, Dan Ports wrote:
> 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.
>
Thanks, committed this.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nick Raj | 2011-04-11 11:33:52 | Global variables in plpgsql |
| Previous Message | Heikki Linnakangas | 2011-04-11 10:58:40 | Re: SSI bug? |