Hello Developers -
I would like to follow up on the suggestion made by Kathey Marsden that
an announcement be posted to derby-user recommending that version 10.3
users upgrade to a Derby version that contains the fix for DERBY-3347.
The email from Binoy Thomas this morning could be an incident of
DERBY-3347 [Subject: DB gets corrupts in 10.3.1.2!!]
In hopes of moving this forward I have drafted such an announcement and
would greatly appreciate review and suggestions from the developers most
familiar with this bug. In the message below I have listed the reported
error and loosely described other errors that might be generated should
a database become corrupted by this defect. I recommend a course of
action and use of database consistency checks. If particularly Knut
would review and comment on the bug related information I would be very
grateful. Word-smithing and other adjustments are also welcome.
If this proposal concerns you please respond or I will assume a lazy
consensus.
And a couple of ideas to give this proposal more weight:
Would a PMC member volunteer to sponsor this post? Having an
acknowledged leader of the development community would give the
recommendation more weight in many circles.
Can the recommendation, if posted, be identified as being made by or at
least supported by the Development Community or a majority of the
Development Community? Again this would give more weight and bring more
attention to the recommendation. As currently worded the recommendation
has no author other than the sender of the message.
*** For Review and comment ***
NOTICE TO ALL DERBY v10.3 USERS : CRITICAL FIX NOW AVAILABLE
The Bottom Line:
It is strongly recommended that you upgrade to Derby 10.4.1.3 to avoid
any chance of database corruption due to DERBY-3347. Alternatively you
can build version 10.3 from the current codeline which also contains the
fix for this defect.
This bug can cause unrecoverable database corruption during periods of
heavy, multi-thread I/O operations. The error produced in the test case
used to diagnose the problem was:
ERROR XSDB3: Container information cannot change once written: was 0,
now 80
It is felt that other errors might also be generated when this type of
corruption occurs. The corruption message will most likely refer to
page 0 of the container.
EXAMPLE: ERROR XSDG1: Page Page(1039,Container(0, 5856)) could not be
written...
This bug corrupts the pages on disk and can go unnoticed. If you do not
run database consistency checks regularly it is recommended you begin
doing so as soon as possible after the upgrade. To insure that
corruption has not already occurred in existing databases, after upgrade
run the database consistency at least once to validate all tables in the
database. This process is documented at:
http://wiki.apache.org/db-derby/DatabaseConsistencyCheck
If corruption has already occurred the database will need to be
recovered from the last good backup.
Version 10.4.1.3 can be downloaded from:
*** END of Proposed Post ***
