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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
