[This is dual posted to firebird-devel, but I would like to have the
discussion on firebird-architect.]

I would like to make all DDL operations atomic, essentially deprecating
the current metadata transaction appearance. In specific, I propose the
following for Vulcan: SQL metadata operations would be performed on a
transient, internal, invisible transaction committed or rolled back when
the statement processing is complete. The net result is that DDL
operations would be atomic and outside of transaction scope.

The engine code in all versions of Interbase and Firebird does not
handle access to uncommitted metadata. All engine metadata access is
performed through a semi-magic system transaction that bypasses
transaction control. The engine, however, has no code to manage access
to uncommitted objects. This hasn't been a serious problem in the past
because most access has been through components that acquire metadata
under transaction control and consequently never generate references to
committed metadata. Preprocessed programs and components emitting BLR
level requests leave the engine exposed to erratic operation, in memory
metadata corruption, engine crashes, or possibly worse. In Interbase
and Firebird the problem is probably more theoretical then practical --
it can be demonstrated by non privileged user code, but that user code
would have to be hand tailored by a knowledgeable individual to show the
problem.

The problem is much more severe in Vulcan. Prior versions of Firebird
had a DSQL implementation that maintained separate metadata caches for
each client that effective prevented manifestations of the problem. In
Vulcan, however, SQL processing uses internal engine metadata, turning a
theoretical problem in Firebird into a major practical problem in Vulcan.

The only adverse impact that I am aware of would be the loss of the
ability to backout a sequence of uncommitted DDL operations, a
non-standard behavior at best. I suspect the scope is limited to the
problems of restarting update scripts during application upgrade
procedures. I believe an "upgrade" DDL verb would be a better way to
address this need.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376