[
https://issues.apache.org/jira/browse/DERBY-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-4881:
-----------------------------------
Attachment: derby-4881-1a-deadlock_fix.diff
Attached patch 1a.
** FromBaseTable
Minor change, avoid second call to TableDescriptor.statisticsExist if
unnecessary.
** DataDictionaryImpl
o Removed getDescriptorViaIndex-overload not taking isolation level as
parameter (only used in once place).
o getStatisticsDescriptors:
- new JavaDoc
- use READ_UNCOMMITTED instead of REPEATABLE_READ
o @@ -8455,16 +8466,16 @@: formatting change due to long line
o getDescriptorViaIndexMinion
- removed unused variable indexTemplateRow
- removed assert allowing only a single result to be returned when using
isolation level read uncommitted
- modified if to ignore match if tuple descriptor is null (index row
existed, but not base row) <=== Behavior change
o computeSequenceRowLocation (cleanup only)
- removed unused variable row
- use getDescriptorViaIndex instead of getDescriptorViaIndexMinion
Regression tests passed: derbyall (104 tests) and suites.All (13075 tests).
Patch ready for review.
> Deadlock accessing SYS.SYSSTATISTICS
> ------------------------------------
>
> Key: DERBY-4881
> URL: https://issues.apache.org/jira/browse/DERBY-4881
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Attachments: derby-4881-1a-deadlock_fix.diff
>
>
> Transactions accessing index statistics can deadlock if one of them inserts
> new entries and the other selects from the system table. Inserts happens for
> instance when update of index statistics are perform manually, or when a
> table is compressed (given that the table has indexes and contains some
> rows). This issue may be more problematic when automatic update of index
> statistics is implemented.
> Issue discovered when writing a regression tests for DERBY-4849, see
> discussion there. The bug is timing dependent, but has been observed on a
> variety of JVMs and platform architectures.
> To sum up:
> o using NO_WAIT + retry was suggested, but turned out to be an infeasible
> solution
> o current approach is to allow using read uncommitted isolation level when
> accessing statistics in the system table (take no locks)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
