db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: Rolling back a transaction leads to an inconsistent state
Date Thu, 29 Mar 2012 08:57:40 GMT
"Brett Mason" <b.mason@adinstruments.com> writes:

> Hi there,
> I think I have encountered a bug where rolling back a transaction can leave
> a table in an inconsistent state if the table has been previously altered
> through the addition of new columns. It appears that if newly added columns
> have not been changed from their default value, then when a transaction
> which sets new values for these columns is rolled back the new columns are
> not restored to their previous values.
> I have attached an ij script with fairly minimal steps to reproduce the
> problem on Derby and (Win7 x64, Sun 32-bit JRE
> Expected and observed output is below.
> There doesn't appear to be an existing bug for this issue. Should I go ahead
> and file one in JIRA?

Hi Brett,

This certainly looks like a bug. Please file a report in JIRA and upload
the repro script there so it can be investigated.

> Can anyone suggest a workaround? Running SYSCS_UTIL.SYSCS_COMPRESS_TABLE on
> the table after it is altered seems to avoid the problem but I'm concerned
> it may be just masking the issue.

That sounds like a useful observation that it would be helpful to
mention in the JIRA report. SYSCS_COMPRESS_TABLE creates a fresh
conglomerate for the table and its indexes, and might be able to fix
some inconsistencies in that process. But these inconsistencies should
of course not have been there in the first place.


Knut Anders

View raw message