Horton

Re: SSI bug?

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Dan Ports <drkp@csail.mit.edu>
Cc: pgsql-hackers@postgresql.org, YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Date: 2011-04-11T11:01:22Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Update key words table for 9.1

  2. Documented some ecpg command line options that were missing:

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