[...] > -----Original Message----- > From: Rick Hillegas [mailto:[email protected]] > Sent: Monday, March 14, 2011 8:45 AM > To: [email protected] > Subject: Re: opinions on a less aggressive release of the istats feature? > > No enthusiasm has been expressed for options (2) or (3). Knut pointed > out on DERBY-5108 that the shutdown problem also affects existing > applications which shutdown in the middle of running the > statistics-updating procedures. I think that istat-on-by-default > increases the risk that this problem will affect production > applications. I don't know how to measure that increased risk. I suppose > it could be significant. > > I am going to pursue option (1), i.e., turn of istat by default. I > propose to do this on the trunk, run regression tests to verify that > everything looks good, let the nightlies vet the change, then cut the > branch tomorrow and re-enable istat on the trunk. I believe that turning > off istat involves the following steps. Does this sound right? > > o Back out the changes which enabled the feature > (derby-4939-1a-enable_istat.diff). This means: > > - Default Property.STORAGE_AUTO_INDEX_STATS=false in DataDictionaryImpl. > - Comment out the addition of AutomaticIndexStatisticsTest and > AutomaticIndexStatisticsMultiTest in the store JUnit suite. > > o Regenerate the 10.8.1 release notes: > > - Remove the summary line for this feature. > - Change the detailed note for DERBY-4939 so that it says that the > feature is disabled by default. > > Thanks, > -Rick > > On 3/11/11 4:26 PM, Rick Hillegas wrote: >> On 3/11/11 3:59 PM, Mike Matrigali wrote: >>> With the 10.8 release coming up quick and the istats feature put into >>> trunk so recently I was wondering what the community would think about >>> a less aggressive release of the feature. No matter what I think it >>> should stay enabled by default in trunk. >>> >>> 2 options I can think of are: >>> 1)disable by default, allowing those users that want the feature >>> to enable it. >> I am comfortable with this default. We can make the change to istat >> shutdown which you recommend on DERBY-5108 and then continue studying >> the behavior of this feature on the trunk. It would be disappointing >> if we had to wait another year before exposing istat-on-by-default. In >> the long run I think that is a better default for a 0-admin database. >> I would support a 10.9 release later this year (maybe even in a couple >> months) when we are more confident about this code. >>> 2)disable by default in all soft upgraded databases. This means that >>> applications not upgrading don't get a surprise background task. >> I'm not keen on this approach. If the feature has shutdown-related >> problems, then that's a showstopper for it being the default in any >> configuration. >> >> Another option would be: >> >> 3) Make the istat shutdown change you recommend and give the code a >> little while to earn our confidence. I would be willing to delay the >> release a week for this approach if we think that's enough time to >> make the change and build confidence. I do not want to push the >> release out further. >> >> Thanks, >> -Rick >>> [...] Looking back over the last week or so, now that there's a probable fix for DERBY-5108, I'm inclined to actually opt for 3). I think it would be better to have this on by default. Making a 10.8 release with it off by default and then on again for a possible 10.8.2 sounds worse.
I'd like opinions about having istat on by default soon (today?) and then giving the tests 3 days before cutting a release. Myrna
