Bug #784: DROP 7.3b1 - DOMIAN CASCADE can leave a table with no columns

Tim Knowles (tim(at)ametco(dot)co(dot)uk) reports a bug with a severity of 4
The lower the number the more severe it is.

Short Description
DROP 7.3b1 - DOMIAN CASCADE can leave a table with no columns

Long Description
Hello,

I've posted this a few times but my email has been playing up a bit - blame British Telecom!, and I can't tell if its been sent.

I have found it is possible for a user with create table permission to crash the 7.3b1 backend. The crash occurs because it is possible to have a table with no columns after a DROP DOMAIN CASCADE. Create a table with one column (with that columns type specified as a domain) then issue the command to DROP DOMAIN ... CASCADE. The column will be dropped from the table, leaving the table with no columns. It is then possible (not surprisngly) to crash the backend by querying that table using a wildcard.

Running the SQL listed at the bottom twice will cause a crash with the following log enteries:

WARNING: ShmemInitStruct: ShmemIndex entry size is wrong
FATAL: LockMethodTableInit: couldn't initialize LockTable

Upon restarting the server the following message appears in the log, each time with a different offset:

LOG: ReadRecord: unexpected pageaddr 0/BA36A000 in log file 0, segment 191, offset 3579904

I am assuming this is a consequence of the abnormal termination but I thought it worth mentioning
for completeness. It also only appears if the SQL below is wrapped up in a transaction.

Sample Code
BEGIN;

CREATE DOMAIN d1 int;

CREATE TABLE t1 (col_a d1);

-- IF YOU DROP DOMAIN d1 CASCADE then col_a WILL BE DROPPED AND THE TABLE t1 WILL HAVE NO COLUMNS

DROP DOMAIN d1 CASCADE;

-- TABLE t1 NOW HAS NO COLUMNS
-- THIS PROBLEM CAN ALSO BE CREATED BY DROP SCHEMA .. CASCADE AS WELL (AS LONG AS THE TABLE IS NOT IN THE SCHEMA BEING DROPPED AND THEREFORE NOT DROPPED AS PART OF THE CASCADE).

-- THE FOLLOWING SELECT WILL CRASH THE BACKEND

SELECT t1.* FROM t1

No file was uploaded with this report