Re: Small SSI issues
От | Kevin Grittner |
---|---|
Тема | Re: Small SSI issues |
Дата | |
Msg-id | 4DF8933B020000250003E69F@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Small SSI issues (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Small SSI issues
Re: Small SSI issues Re: Small SSI issues |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: