Skip site navigation (1) Skip section navigation (2)

Re: SSI bug?

From: Dan Ports <drkp(at)csail(dot)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Cc: 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-03 06:16:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

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

Takashi, does this patch fix your problem with leaked SIReadLocks?


Dan R. K. Ports              MIT CSAIL      

Attachment: patch-commitseqno.diff
Description: text/x-diff (2.3 KB)

In response to


pgsql-hackers by date

Next:From: Dave PageDate: 2011-04-03 07:30:18
Subject: FDW state from plan time
Previous:From: Shigeru HanadaDate: 2011-04-03 01:51:04
Subject: Re: Re: [COMMITTERS] pgsql: Support comments on FOREIGN DATA WRAPPER and SERVER objects.

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group