Bryan Pendleton wrote:
The store's metadata thinks that there are 20 columns in the table, and
it only currently supports adding a column at the end of the table. The
request is to add the column at position 16, in the middle. From
I notice that the overall algorithm for adding a column to a table
(in AlterTableConstantAction.addNewColumnToTable) is:
- add new column to conglomerate
- add new column to system catalogs
the actions that implement these 2 steps are logged operations. What
is supposed to happen is if any error is encountered any point in the
alter table statement then at least a statement level backout should
be generated by the system and all updates are backed out. Session
failure and server failure at some intermediate step are handled with
the same mechanism.
So we may be looking for some error path in alter table which somehow
fails to update the system catalogs but still allows the statement to
commit.
Some things that could help is:
does your app tend to use autocommit when it is doing the alter table?
Any way to gather info about errors your app may have encountered in the
past while trying to do the alter table?
I wonder if there are situations in which something goes wrong in
the second step, and we don't clean up properly, resulting in a
situation in which the conglomerate's notion of the columns becomes
out of sync with the system catalogs?
Alan, does your application routinely add columns to tables?
If so, have there been times in which something went wrong with
adding the column to the table, and the request failed and had to
be repeated?
Presumably, for this particular table, this would need to have
happened 5 times already.
Just an idea, thought I'd throw it out there to see if it gave any
further theories to pursue.
thanks,
bryan
