db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4849) Re-compilation may cause duplicate entries in the XPLAIN table
Date Mon, 18 Oct 2010 21:34:30 GMT

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

Knut Anders Hatlen commented on DERBY-4849:

I agree that 2a sounds like a good approach. Some comments on the patch:

The name of the flag and the method may cause some confusion. The flag is set if the execution
failed because the plan was invalidated. The plan has not necessarily been recompiled at that
time, and the recompiling may in fact be performed by the same thread after processing the
exception, if no other thread beats it to it. So perhaps rename to planWasInvalidated?

I'm wondering, though, what's the intended behaviour when the execution fails for some other
reason? Currently we add rows into SYSXPLAIN_STATEMENTS regardless of the statement's successful
execution, but should we have been suppressing all failed executions? If so, we could set
the flag unconditionally in cleanupOnError(). But that may be outside the scope of this issue,
unless it's obvious that the current behaviour is unintended.

Do we know for sure that StandardException.getMessageId() will never return null? Probably...
But just to be 100% that we don't cause a NPE in the error handling, should we turn around
message id check in cleanupOnError() and call equals() on LANG_STATEMENT_NEEDS_RECOMPILE,
which is known to be non-null?

The comment in cleanupOnError() has a small typo: s/optimalization/optimization/

> Re-compilation may cause duplicate entries in the XPLAIN table
> --------------------------------------------------------------
>                 Key: DERBY-4849
>                 URL: https://issues.apache.org/jira/browse/DERBY-4849
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:,
>            Reporter: Kristian Waagan
>            Priority: Minor
>         Attachments: derby-4849-1a-narrow_fix.diff, derby-4849-2a-broad_fix.diff, derby-4849-xplain_duplicate_stacktrace.txt
> If happening at the right moment, a re-compilation request may cause duplicate entries
in the XPLAIN statement tables.
> I have only confirmed this for the SYSXPLAIN_STATEMENTS table, and I do not know if the
other XPLAIN tables are affected.
> The error is highly intermittent, and so far I have only been able to trigger it when
testing the automatic index statistics update prototype.
> See the attached stack-trace for some more details.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message