Hello,
I've mailed this to the bugs list but that seems to have stopped working on
the 24th so I thought I'd better email it through on here.
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.
To recreate the problem enter the following SQL in psql:-
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
