Tim Knowles (tim@ametco.co.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
beensent.
I have found it is possible for a user with create table permission to crash the 7.3b1 backend. The crash occurs
becauseit is possible to have a table with no columns after a DROP DOMAIN CASCADE. Create a table with one column
(withthat columns type specified as a domain) then issue the command to DROP DOMAIN ... CASCADE. The column will be
droppedfrom the table, leaving the table with no columns. It is then possible (not surprisngly) to crash the backend
byquerying 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
DROPPEDAND 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
