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

Re: SSI memory mitigation & false positive degradation

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <drkp(at)csail(dot)mit(dot)edu>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI memory mitigation & false positive degradation
Date: 2010-12-29 18:47:37
Message-ID: 4D1B2DE90200002500038D86@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
 
>> Any chance of upgrading the lock to a relation lock, or killing
>> the serializable transaction instead?
>  
> Absolutely.  Good suggestion.  Thanks!
 
I pushed a TODO SSI comment at the appropriate point with my ideas
on how best to fix this.  I want to stick with the SLRU changes for
now, rather than risk flushing "brain cache" on the topic just now. 
If Dan (or anyone else, for that matter) wants to fix this, feel
free; just post first, as will I if nobody beats me to it.
 
There are actually two spots in PredicateLockPageSplit and one in
PredicateLockPageCombine where this needs to be addressed.  I can't
think of any other functions where we're vulnerable to having an
impact on non-serializable transactions.  We sure want to plug those
-- I see it as critical to acceptance that we can honor the promise
of no impact on any transactions at REPEATABLE READ or less strict
isolation levels.
 
-Kevin

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-12-29 18:47:54
Subject: Re: Avoiding rewrite in ALTER TABLE ALTER TYPE
Previous:From: Bruce MomjianDate: 2010-12-29 18:44:27
Subject: Re: TODO item for pg_ctl and server detection

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