Thread

Re: Small SSI issues

Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-06-15T16:10:51Z

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
 
>> There may be some places this can be checked which haven't yet
>> been identified and touched.
> 
> Yeah - in 9.2.
 
No argument here.  I'm all for stabilizing and getting the thing out
-- I think we've established that performance is good for many
workloads as it stands, and that there are workloads where it will
never be useful.  Chipping away at the gray area, to make it perform
well in a few workloads where it currently doesn't (and, of course,
*even better* in workloads where it's currently better than the
alternatives), seems like future release work to me.
 
There is one issue you raised in this post:
 
http://archives.postgresql.org/message-id/4DEF3194.6030305@enterprisedb.com
 
Robert questioned whether it should be 9.1 material here:
 
http://archives.postgresql.org/message-id/BANLkTint2i2fHDTdr=Xq3K=YrxegovGmTw@mail.gmail.com
 
I posted a patch here:
 
http://archives.postgresql.org/message-id/4DEFB169020000250003E3BD@gw.wicourts.gov
 
Should I put that patch into a 9.2 CF?
 
There is an unnecessary include of predicate.h in nbtree.c we should
delete.  That seems safe enough.
 
You questioned whether OldSerXidPagePrecedesLogically was buggy.  I
will look at that by this weekend at the latest.  If it is buggy we
obviously should fix that.  Are there any other changes you think we
should make to handle the odd corner cases in the SLRU for SSI?  It
did occur to me that we should be safe from actual overwriting of an
old entry by the normal transaction wrap-around protections -- the
worst that should happen with the current code (I think) is that in
extreme cases we may get LOG level messages or accumulate a
surprising number of SLRU segment files.  That's because SLRU will
start to nag about things at one billion transactions, but we need
to get all the way to two billion transactions used up while a
single serializable transaction remains active before we could
overwrite something.
 
It seems like it might be a good idea to apply pgindent formating to
the latest SSI changes, to minimize conflict on back-patching any
bug fixes.  I've attached a patch to do this formatting -- entirely
whitespace changes from a pgindent run against selected files.
 
Unless I'm missing something, the only remaining changes needed are
for documentation (as mentioned in previous posts).  I will work on
those after I look at OldSerXidPagePrecedesLogically.
 
-Kevin