Derby
  1. Derby
  2. DERBY-4127

ArrayIndexOutOfBoundsException in DatabaseMetaDataTest when run in Soft Upgrade mode

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.5.1.1
    • Component/s: Test
    • Labels:
      None
    • Environment:
      Windows Vista 64, Junit 3.8.2, Sun JDK 1.6.0_10
    • Urgency:
      Urgent
    • Bug behavior facts:
      Regression Test Failure

      Description

      This bug was found when doing soft upgrade testing from Derby version 10.4.2.0 to 10.5.1.0 (RC1)

      Steps followed are as follows.

      1. Run setEmbeddedCP.bat from version 10.4.2.0's bin folder
      2. In a test folder run ij
      3. create system/wombat database.
      ij> connect 'jdbc:derby:system/wombat;create=true';
      4. exit ij
      5. Copy the 10.5.1.0 derby jars (from lib folder) and the derbyTesting.jar from 10.4.2.0 to the test folder and set classpath with them (including junit and ORO)
      6. Run suites.All
      java -Xmx512M -Xms512M -Dderby.tests.trace=true junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All

      Result:
      Tests run: 10479, Failures: 56, Errors: 34

      The stack trace is as follows.
      ---------------------------------------------------------------------------------------------------------
      21) testGetColumnsReadOnly(org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest)java.lang.ArrayIndexOutOfBoundsException: 122
      at org.apache.derby.client.net.NetCursor.readFdocaBytes(Unknown Source)
      at org.apache.derby.client.net.NetCursor.parseSQLCAXGRP(Unknown Source)
      at org.apache.derby.client.net.NetCursor.parseSQLCAGRP(Unknown Source)
      at org.apache.derby.client.net.NetCursor.parseSQLCARD(Unknown Source)
      at org.apache.derby.client.net.NetCursor.calculateColumnOffsetsForRow_(Unknown Source)
      at org.apache.derby.client.am.Cursor.stepNext(Unknown Source)
      at org.apache.derby.client.net.NetCursor.scanDataBufferForEndOfData(Unknown Source)
      at org.apache.derby.client.net.NetResultSet.preClose_(Unknown Source)
      at org.apache.derby.client.am.ResultSet.closeX(Unknown Source)
      at org.apache.derby.client.am.ResultSet.close(Unknown Source)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.crossCheckGetColumnsAndResultSetMetaData(DatabaseMetaDataTest.java:1660)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetColumnsReadOnly(DatabaseMetaDataTest.java:1357)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:102)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

      22) testGetColumnsModify(org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest)java.lang.ArrayIndexOutOfBoundsException: 122
      at org.apache.derby.client.net.NetCursor.readFdocaBytes(Unknown Source)
      at org.apache.derby.client.net.NetCursor.parseSQLCAXGRP(Unknown Source)
      at org.apache.derby.client.net.NetCursor.parseSQLCAGRP(Unknown Source)
      at org.apache.derby.client.net.NetCursor.parseSQLCARD(Unknown Source)
      at org.apache.derby.client.net.NetCursor.calculateColumnOffsetsForRow_(Unknown Source)
      at org.apache.derby.client.am.Cursor.stepNext(Unknown Source)
      at org.apache.derby.client.net.NetCursor.scanDataBufferForEndOfData(Unknown Source)
      at org.apache.derby.client.net.NetResultSet.preClose_(Unknown Source)
      at org.apache.derby.client.am.ResultSet.closeX(Unknown Source)
      at org.apache.derby.client.am.ResultSet.close(Unknown Source)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.crossCheckGetColumnsAndResultSetMetaData(DatabaseMetaDataTest.java:1660)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetColumnsReadOnly(DatabaseMetaDataTest.java:1357)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetColumnsModify(DatabaseMetaDataTest.java:1374)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:102)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      ----------------------------------------------------------------------------------

      I did not see anything in the derby.log from the tests that seemed to be related to this.

      Note that this test passed when run by itself, and also when run after a couple of failing tests (namely org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest and org.apache.derbyTesting.functionTests.tests.jdbcapi.UpdatableResultSetTest)

      1. Test4127.java
        1 kB
        Rick Hillegas
      2. derby-4127-aa-01-refactorPrivs.diff
        33 kB
        Rick Hillegas

        Issue Links

          Activity

          Hide
          Dag H. Wanvik added a comment -

          Running with sane jars from head of 10.5 branch I see this also. Here is the stack trace with line numbers for the client side:

          java.lang.ArrayIndexOutOfBoundsException: 122
          at org.apache.derby.client.net.NetCursor.readFdocaBytes(NetCursor.java:516)
          at org.apache.derby.client.net.NetCursor.parseSQLCAXGRP(NetCursor.java:825)
          at org.apache.derby.client.net.NetCursor.parseSQLCAGRP(NetCursor.java:732)
          at org.apache.derby.client.net.NetCursor.parseSQLCARD(NetCursor.java:705)
          at org.apache.derby.client.net.NetCursor.calculateColumnOffsetsForRow_(NetCursor.java:148)
          at org.apache.derby.client.am.Cursor.stepNext(Cursor.java:182)
          at org.apache.derby.client.net.NetCursor.scanDataBufferForEndOfData(NetCursor.java:385)
          at org.apache.derby.client.net.NetResultSet.preClose_(NetResultSet.java:260)
          at org.apache.derby.client.am.ResultSet.closeX(ResultSet.java:439)
          at org.apache.derby.client.am.ResultSet.close(ResultSet.java:416)
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.crossCheckGetColumnsAndResultSetMetaData(DatabaseMetaDataTest.java:1660)
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetColumnsReadOnly(DatabaseMetaDataTest.java:1357)

          Show
          Dag H. Wanvik added a comment - Running with sane jars from head of 10.5 branch I see this also. Here is the stack trace with line numbers for the client side: java.lang.ArrayIndexOutOfBoundsException: 122 at org.apache.derby.client.net.NetCursor.readFdocaBytes(NetCursor.java:516) at org.apache.derby.client.net.NetCursor.parseSQLCAXGRP(NetCursor.java:825) at org.apache.derby.client.net.NetCursor.parseSQLCAGRP(NetCursor.java:732) at org.apache.derby.client.net.NetCursor.parseSQLCARD(NetCursor.java:705) at org.apache.derby.client.net.NetCursor.calculateColumnOffsetsForRow_(NetCursor.java:148) at org.apache.derby.client.am.Cursor.stepNext(Cursor.java:182) at org.apache.derby.client.net.NetCursor.scanDataBufferForEndOfData(NetCursor.java:385) at org.apache.derby.client.net.NetResultSet.preClose_(NetResultSet.java:260) at org.apache.derby.client.am.ResultSet.closeX(ResultSet.java:439) at org.apache.derby.client.am.ResultSet.close(ResultSet.java:416) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.crossCheckGetColumnsAndResultSetMetaData(DatabaseMetaDataTest.java:1660) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetColumnsReadOnly(DatabaseMetaDataTest.java:1357)
          Hide
          Myrna van Lunteren added a comment -

          I haven't analyzed all my test runs yet, but so far I don't see this one.
          I wonder - I believe the DatabaseMetaDataTest runs a couple of times as part of the upgrade tests. Is that when DatabaseMetaDataTest is run as part of the upgrade tests or when run by itself later?

          Show
          Myrna van Lunteren added a comment - I haven't analyzed all my test runs yet, but so far I don't see this one. I wonder - I believe the DatabaseMetaDataTest runs a couple of times as part of the upgrade tests. Is that when DatabaseMetaDataTest is run as part of the upgrade tests or when run by itself later?
          Hide
          Kathey Marsden added a comment -

          the key is that it has to be run on a soft upgraded (from 10.4) database. i.e. Create the database system/wombat with 10.4.2.0 and then run with the 10.4 testing jar and the 10.5 product jars, so you wouldn't have seen it in your normal test runs.

          As for what mode it is run in, that is a really excellent point. This is the 10th time the test is run in the test suite that it fails. What variation of the test that is I don't know, but it would be worth trying to figure out so we can get a smaller repro than running the whole suite.

          Show
          Kathey Marsden added a comment - the key is that it has to be run on a soft upgraded (from 10.4) database. i.e. Create the database system/wombat with 10.4.2.0 and then run with the 10.4 testing jar and the 10.5 product jars, so you wouldn't have seen it in your normal test runs. As for what mode it is run in, that is a really excellent point. This is the 10th time the test is run in the test suite that it fails. What variation of the test that is I don't know, but it would be worth trying to figure out so we can get a smaller repro than running the whole suite.
          Hide
          Kathey Marsden added a comment -

          I tried running lang.CollationTests and upgredeTests._Suite independently with the soft upgrade setup, and did not see the issue. Suran also tried running DatabaseMetaDataTest on its own and it didn't reproduce. I don't immediately see other configurations in which it is run.

          Show
          Kathey Marsden added a comment - I tried running lang.CollationTests and upgredeTests._Suite independently with the soft upgrade setup, and did not see the issue. Suran also tried running DatabaseMetaDataTest on its own and it didn't reproduce. I don't immediately see other configurations in which it is run.
          Hide
          Dag H. Wanvik added a comment -

          The error occurs when DatabaseMetaDataTest is run from inside jdbcapi/_Suite - i.e. just before ClosedObjectTest is run.
          That is, the entire lang suite has been run prior to jdbcapi. I will try to run jdbcapi/_Suite separately and see if it
          reproduces.

          Show
          Dag H. Wanvik added a comment - The error occurs when DatabaseMetaDataTest is run from inside jdbcapi/_Suite - i.e. just before ClosedObjectTest is run. That is, the entire lang suite has been run prior to jdbcapi. I will try to run jdbcapi/_Suite separately and see if it reproduces.
          Hide
          Dag H. Wanvik added a comment -

          I can reproduce the error by running just jdbcapi/_Suite.

          Show
          Dag H. Wanvik added a comment - I can reproduce the error by running just jdbcapi/_Suite.
          Hide
          Dag H. Wanvik added a comment -

          If I uncomment all tests in jdbcapi/_Suite before DatabaseMetaDataTest, except DboPowersTest, I can see the error.
          Somehow it seems the problem is a side-effect of DboPowersTest, which does shut down the wombat database and bring back up again.

          Show
          Dag H. Wanvik added a comment - If I uncomment all tests in jdbcapi/_Suite before DatabaseMetaDataTest, except DboPowersTest, I can see the error. Somehow it seems the problem is a side-effect of DboPowersTest, which does shut down the wombat database and bring back up again.
          Hide
          Dag H. Wanvik added a comment - - edited

          Of one the test cases inside DboPowersTest actually leads to a hard upgrade of wombat to 10.5. This seems to
          precipitate the error. (DboPowersTest works on the assumption that the hard upgrade here is just a normal reboot;
          the intention being to just test the powers to specify hard upgrade. Obviously, when we have created wombat with 10.4 that assumption no longer holds. But why a hard upgrade should make the subsequent DatabaseMetaDataTest fail is another matter..)

          Show
          Dag H. Wanvik added a comment - - edited Of one the test cases inside DboPowersTest actually leads to a hard upgrade of wombat to 10.5. This seems to precipitate the error. (DboPowersTest works on the assumption that the hard upgrade here is just a normal reboot; the intention being to just test the powers to specify hard upgrade. Obviously, when we have created wombat with 10.4 that assumption no longer holds. But why a hard upgrade should make the subsequent DatabaseMetaDataTest fail is another matter..)
          Hide
          Dag H. Wanvik added a comment -

          Right, I have confirmed this. By creating wombat at 10.4, then hard upgrading to 10.5 using ij,
          and just running DatabaseMetaDataTest, I see the error.
          So somehow, the hard upgrade isn't working correctly.

          (It may be useful to make DboPowersTest test its thing on a another database than wombat to be able to run the entire regression in a soft upgrade mode, but that would be another issue).

          Show
          Dag H. Wanvik added a comment - Right, I have confirmed this. By creating wombat at 10.4, then hard upgrading to 10.5 using ij, and just running DatabaseMetaDataTest, I see the error. So somehow, the hard upgrade isn't working correctly. (It may be useful to make DboPowersTest test its thing on a another database than wombat to be able to run the entire regression in a soft upgrade mode, but that would be another issue).
          Hide
          Kathey Marsden added a comment -

          Thanks Dag for looking at this issue. I will kick off a hard upgrade run to see if we hit any other issues with hard upgrade. Do you think this issue should be BLOCKER since the on disk format has come into question and may be difficult to fix after release?

          Show
          Kathey Marsden added a comment - Thanks Dag for looking at this issue. I will kick off a hard upgrade run to see if we hit any other issues with hard upgrade. Do you think this issue should be BLOCKER since the on disk format has come into question and may be difficult to fix after release?
          Hide
          Dag H. Wanvik added a comment -

          I agree, Kathey. Moving to blocker, at least until we know the root cause.

          Show
          Dag H. Wanvik added a comment - I agree, Kathey. Moving to blocker, at least until we know the root cause.
          Hide
          Rick Hillegas added a comment -

          Attaching Test4127.java. This is a small program which reproduces the problem. The program does the following:

          o Connects to the upgraded database

          o Gets a ResultSet for selecting all of SYS.SYSROUTINEPERMS

          o Gets and then immediately closes the ResultSetMetaData on the ResultSet above

          To reproduce the problem, do the following:

          o Create a 10.4 database

          o Hard-upgrade it to 10.5

          o Bring up a 10.5 network server

          o Run the program specifying a network connection url to the upgraded database, like this:

          java Test4127 "jdbc:derby://localhost:8246/wombat10.4to10.5"

          Show
          Rick Hillegas added a comment - Attaching Test4127.java. This is a small program which reproduces the problem. The program does the following: o Connects to the upgraded database o Gets a ResultSet for selecting all of SYS.SYSROUTINEPERMS o Gets and then immediately closes the ResultSetMetaData on the ResultSet above To reproduce the problem, do the following: o Create a 10.4 database o Hard-upgrade it to 10.5 o Bring up a 10.5 network server o Run the program specifying a network connection url to the upgraded database, like this: java Test4127 "jdbc:derby://localhost:8246/wombat10.4to10.5"
          Hide
          Rick Hillegas added a comment -

          I have looked into this problem and would like to summarize what I have observed:

          1) Simple test case

          2) Scope of problem

          3) Suspect code

          4) Proposed solution (10.5)

          5) Future improvements (10.6)

          ------- (1) Simple Test Case ---------------

          Here is a simple way to reproduce this problem:

          A) Hard-upgrade a 10.4 (or earlier) database to 10.5

          B) Bring up the 10.5 network server

          C) Run the following query through ij over the network:

          select * from sys.sysroutineperms

          I didn't spend any time looking into the ugly network error. I wrote it off as just another example of the obscure diagnostics which the network layer barks when it trips over a puzzling condition. I believe that the underlying problem which muddled the network layer was the presence of a null in a non-nullable column.

          More specifically, the same query run through the embedded driver shows a corrupt permission tuple. The PUBLIC permission granted to SYSCS_UPDATE_STATISTICS has a null GRANTOR column. GRANTOR is a non-nullable column and it should contain the name of the database owner.

          The tuple should be

          ( permissionID = someUUID, grantee = PUBLIC, grantor = databaseOwner, aliasID = updateStatisticsUUID, grantOption = N )

          but is instead

          ( permissionID = someUUID, grantee = PUBLIC, grantor = NULL, aliasID = updateStatisticsUUID, grantOption = N )

          An extra complication of this corruption occurs if a database is hard-upgraded from 10.0 to 10.5. In that case, the metadata holds two versions of the permission: the correct version and the corrupt version.

          ------- (2) Scope of the Problem ---------------

          I believe that this corrupt metadata is benign for the moment. That is, I don't believe that this corruption causes Derby to malfunction in any serious way--other than exposing some brittleness in the network layer. However, I think that corrupt metadata is a ticking timebomb and we should not make the metadata more corrupt than it already is.

          In investigating this problem, I discovered another example of this corruption which may have crept into Derby databases already. The permission granted to SYSCS_INPLACE_COMPRESS_TABLE has a null GRANTOR column if the database was hard-upgraded from 10.0 to 10.2 or later. Note that the corruption does not appear in databases which underwent an intermediate upgrade to 10.1 before being hard-upgraded to a later release. So the corrupt upgrade trajectories are:

          10.0 -> 10.2
          10.0 -> 10.3
          10.0 -> 10.4

          but the following trajectories are ok:

          10.0 -> 10.1 -> 10.2
          10.0 -> 10.1 -> 10.3
          10.0 -> 10.1 -> 10.4

          ------- (3) Suspect Code ---------------

          To recap, we see two upgrade problems:

          i) A NULL GRANTOR column in a permission tuple--seen in all hard-upgrades to 10.5.

          ii) Redundant permission tuples--seen when you hard-upgrade from 10.0.

          I believe these problems are caused by the following issues in Derby's metadata management:

          i) We calculate the database owner AFTER upgrade. I think this was a deliberate decision. Calculating the database owner AFTER upgrade gives you the correct owner when you hard-upgrade to 10.2 or later. That is because 10.2 changes the database owner. However, this late calculation means that the database owner is NULL during upgrade--and that is why we stuff NULL into the GRANTOR column.

          ii) We declare the list of PUBLIC routines twice: first in a tidy table and then again in procedural logic. This redundant declaration results in multiple copies of the same permission.

          ------- (4) Proposed solution (10.5) ---------------

          I recommend the following immediate changes to 10.5 and the trunk:

          i) Calculate the database owner BEFORE the database is upgraded. Then recalculate the database owner during upgrade if we have to run the 10.2 logic which changes the database owner.

          ii) Declare the list of PUBLIC routines only once. I think this means removing one of the existing declarations. Removing the tidy tables requires fewer code changes but results in code that is harder to understand. Removing the procedural redundancies causes a lot of edits but leaves you with a tidy declaration of the PUBLIC routines which you understand at a glance. I vote for this solution.

          ------- (5) Future improvements (10.6) ---------------

          Even after making the changes in (4), we are still left with the corrupt permission for SYSCS_INPLACE_COMPRESS_TABLE in databases which were hard-upgraded as follows:

          10.0 -> 10.2
          10.0 -> 10.3
          10.0 -> 10.4

          We could add some 10.5 upgrade logic which corrects this corruption. However, since I think the corruption is benign for the moment and no-one has complained about it yet, I recommend that we defer this correction until the 10.6 upgrade. I also recommend that we write a comprehensive test which compares virgin metadata with hard-upgraded metadata. We should run this test on all hard-upgrade trajectories. This may uncover other corruptions in Derby metadata. We should correct those other corruptions in 10.6 too.

          Show
          Rick Hillegas added a comment - I have looked into this problem and would like to summarize what I have observed: 1) Simple test case 2) Scope of problem 3) Suspect code 4) Proposed solution (10.5) 5) Future improvements (10.6) ------- (1) Simple Test Case --------------- Here is a simple way to reproduce this problem: A) Hard-upgrade a 10.4 (or earlier) database to 10.5 B) Bring up the 10.5 network server C) Run the following query through ij over the network: select * from sys.sysroutineperms I didn't spend any time looking into the ugly network error. I wrote it off as just another example of the obscure diagnostics which the network layer barks when it trips over a puzzling condition. I believe that the underlying problem which muddled the network layer was the presence of a null in a non-nullable column. More specifically, the same query run through the embedded driver shows a corrupt permission tuple. The PUBLIC permission granted to SYSCS_UPDATE_STATISTICS has a null GRANTOR column. GRANTOR is a non-nullable column and it should contain the name of the database owner. The tuple should be ( permissionID = someUUID, grantee = PUBLIC, grantor = databaseOwner, aliasID = updateStatisticsUUID, grantOption = N ) but is instead ( permissionID = someUUID, grantee = PUBLIC, grantor = NULL, aliasID = updateStatisticsUUID, grantOption = N ) An extra complication of this corruption occurs if a database is hard-upgraded from 10.0 to 10.5. In that case, the metadata holds two versions of the permission: the correct version and the corrupt version. ------- (2) Scope of the Problem --------------- I believe that this corrupt metadata is benign for the moment. That is, I don't believe that this corruption causes Derby to malfunction in any serious way--other than exposing some brittleness in the network layer. However, I think that corrupt metadata is a ticking timebomb and we should not make the metadata more corrupt than it already is. In investigating this problem, I discovered another example of this corruption which may have crept into Derby databases already. The permission granted to SYSCS_INPLACE_COMPRESS_TABLE has a null GRANTOR column if the database was hard-upgraded from 10.0 to 10.2 or later. Note that the corruption does not appear in databases which underwent an intermediate upgrade to 10.1 before being hard-upgraded to a later release. So the corrupt upgrade trajectories are: 10.0 -> 10.2 10.0 -> 10.3 10.0 -> 10.4 but the following trajectories are ok: 10.0 -> 10.1 -> 10.2 10.0 -> 10.1 -> 10.3 10.0 -> 10.1 -> 10.4 ------- (3) Suspect Code --------------- To recap, we see two upgrade problems: i) A NULL GRANTOR column in a permission tuple--seen in all hard-upgrades to 10.5. ii) Redundant permission tuples--seen when you hard-upgrade from 10.0. I believe these problems are caused by the following issues in Derby's metadata management: i) We calculate the database owner AFTER upgrade. I think this was a deliberate decision. Calculating the database owner AFTER upgrade gives you the correct owner when you hard-upgrade to 10.2 or later. That is because 10.2 changes the database owner. However, this late calculation means that the database owner is NULL during upgrade--and that is why we stuff NULL into the GRANTOR column. ii) We declare the list of PUBLIC routines twice: first in a tidy table and then again in procedural logic. This redundant declaration results in multiple copies of the same permission. ------- (4) Proposed solution (10.5) --------------- I recommend the following immediate changes to 10.5 and the trunk: i) Calculate the database owner BEFORE the database is upgraded. Then recalculate the database owner during upgrade if we have to run the 10.2 logic which changes the database owner. ii) Declare the list of PUBLIC routines only once. I think this means removing one of the existing declarations. Removing the tidy tables requires fewer code changes but results in code that is harder to understand. Removing the procedural redundancies causes a lot of edits but leaves you with a tidy declaration of the PUBLIC routines which you understand at a glance. I vote for this solution. ------- (5) Future improvements (10.6) --------------- Even after making the changes in (4), we are still left with the corrupt permission for SYSCS_INPLACE_COMPRESS_TABLE in databases which were hard-upgraded as follows: 10.0 -> 10.2 10.0 -> 10.3 10.0 -> 10.4 We could add some 10.5 upgrade logic which corrects this corruption. However, since I think the corruption is benign for the moment and no-one has complained about it yet, I recommend that we defer this correction until the 10.6 upgrade. I also recommend that we write a comprehensive test which compares virgin metadata with hard-upgraded metadata. We should run this test on all hard-upgrade trajectories. This may uncover other corruptions in Derby metadata. We should correct those other corruptions in 10.6 too.
          Hide
          Rick Hillegas added a comment -

          Attaching derby-4127-aa-01-refactorPrivs.diff. This patch makes the changes described in (4i) and (4ii) above. This fixes the original problem and makes SYS.SYSROUTINEPERMS look correct after hard-upgrading from 10.4 to 10.5. I am running regression tests now.

          This patch makes the following changes:

          a) The database owner is now calculated BEFORE upgrade rather than AFTER upgrade

          b) The hard-upgrade logic for 10.2 now recalculates the database owner after changing it.

          (ii)

          c) Permission-creating logic has been removed from the release-specific methods which add system routines.

          d) Instead, we now keep track of which system routines we are adding.

          e) After adding system routines (at the end of database creation and hard-upgrade), we call a method which adds permissions for the public routines which appear in the list of routines we have just added.

          This patch does not add any additional tests. That work is deferred until 10.6 when we will write a comprehensive test that will compare virgin metadata to hard-upgraded metadata along all upgrade trajectories.

          Touches the following files:

          M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java
          M java/engine/org/apache/derby/impl/sql/catalog/DD_Version.java

          Show
          Rick Hillegas added a comment - Attaching derby-4127-aa-01-refactorPrivs.diff. This patch makes the changes described in (4i) and (4ii) above. This fixes the original problem and makes SYS.SYSROUTINEPERMS look correct after hard-upgrading from 10.4 to 10.5. I am running regression tests now. This patch makes the following changes: a) The database owner is now calculated BEFORE upgrade rather than AFTER upgrade b) The hard-upgrade logic for 10.2 now recalculates the database owner after changing it. (ii) c) Permission-creating logic has been removed from the release-specific methods which add system routines. d) Instead, we now keep track of which system routines we are adding. e) After adding system routines (at the end of database creation and hard-upgrade), we call a method which adds permissions for the public routines which appear in the list of routines we have just added. This patch does not add any additional tests. That work is deferred until 10.6 when we will write a comprehensive test that will compare virgin metadata to hard-upgraded metadata along all upgrade trajectories. Touches the following files: M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java M java/engine/org/apache/derby/impl/sql/catalog/DD_Version.java
          Hide
          Rick Hillegas added a comment -

          Tests ran cleanly for me. I will hold off committing this patch until Monday to give people an opportunity to review it. Thanks.

          Show
          Rick Hillegas added a comment - Tests ran cleanly for me. I will hold off committing this patch until Monday to give people an opportunity to review it. Thanks.
          Hide
          Kathey Marsden added a comment -

          I ran suites.All against 10.3.3.0 and 10.4.2.0->10.5 (with the patch) hard upgraded databases and did not see the failure. Nor did I see the testReplication_Local_StateTest_part1 failure I had seen in earlier runs. So that must have been either a different manifestation of this issue or just coincidental instability in the replication tests.

          Show
          Kathey Marsden added a comment - I ran suites.All against 10.3.3.0 and 10.4.2.0->10.5 (with the patch) hard upgraded databases and did not see the failure. Nor did I see the testReplication_Local_StateTest_part1 failure I had seen in earlier runs. So that must have been either a different manifestation of this issue or just coincidental instability in the replication tests.
          Hide
          Rick Hillegas added a comment -

          Committed derby-4127-aa-01-refactorPrivs.diff at subversion revision 764471.

          Show
          Rick Hillegas added a comment - Committed derby-4127-aa-01-refactorPrivs.diff at subversion revision 764471.
          Hide
          Rick Hillegas added a comment -

          Ported 764471 from the 10.5 branch to the trunk at subversion revision 764481.

          Show
          Rick Hillegas added a comment - Ported 764471 from the 10.5 branch to the trunk at subversion revision 764481.
          Hide
          Rick Hillegas added a comment -

          Fixed javadoc error introduced by 764471. Fixed 10.5 branch at subversion revision 764932. Ported to main at subversion revision 764939.

          Show
          Rick Hillegas added a comment - Fixed javadoc error introduced by 764471. Fixed 10.5 branch at subversion revision 764932. Ported to main at subversion revision 764939.

            People

            • Assignee:
              Rick Hillegas
              Reporter:
              Suran Jayathilaka
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development