[jira] [Commented] (DERBY-6283) indexStat daemon processing tables over and over even when there are no changes in the tables in soft upgraded database.

["Mike Matrigali (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13695575#comment-13695575 ] 

Mike Matrigali commented on DERBY-6283:
---------------------------------------

Would like to get consensus on the following:
1) should we always drop orphaned stats, even in soft upgraded databases (I believe yes)
2) should we not drop orphan stats, if the keep disposable stats flag is set (I can see arguments both ways)
                
> indexStat daemon processing tables over and over even when there are no changes in the tables in soft upgraded database.
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-6283
>                 URL: https://issues.apache.org/jira/browse/DERBY-6283
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.8.3.1, 10.9.2.2, 10.10.1.3, 10.11.0.0
>            Reporter: Mike Matrigali
>            Priority: Blocker
>              Labels: derby_backport_reject_10_7
>
> The fix for DERBY-5680 currently requires hard upgrade.  A soft upgrade database with an orphaned stat row, that can be caused by something like DERBY-5681, will cause DERBY to spin eating up 100% of a cpu and possibly all the disk bandwith of the disk where the database is located.
> We should implement a fix that can be applied to soft upgraded databases if at all possible.
> In soft upgraded databases we can no use the work around of dropping the statistics as it is not available
> to soft upgraded db's with version < 10.9.  The only current workaround is to disable background stats
> completely.  Dropping and recreating the suspect table may also work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira