Re: [BUGS] 6.5.2 BUG: Rolling back after dropping a table causes dangling relationships. - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: [BUGS] 6.5.2 BUG: Rolling back after dropping a table causes dangling relationships.
Date
Msg-id 199910081613.MAA26030@candle.pha.pa.us
Whole thread Raw
In response to 6.5.2 BUG: Rolling back after dropping a table causes dangling relationships.  (Lincoln Yeoh <lylyeoh@mecomb.com>)
List pgsql-bugs
This will be fixed in 6.6, due out in a few months.


> Your name               : Lincoln Yeoh
> Your email address      : lylyeoh@mecomb.com
>
> System Configuration
> ---------------------
> Architecture (example: Intel Pentium)   :   Intel Pentium II (64MB)
> Operating System (example: Linux 2.0.26 ELF)    :  Redhat 6.0 Linux
> 2.2.5-15 ELF
> PostgreSQL version (example: PostgreSQL-6.5.1):   PostgreSQL-6.5.2
> Compiler used (example:  gcc 2.8.0)             :   egcs-2.91.66
>
> Please enter a FULL description of your problem:
> ------------------------------------------------
> If you drop a table in a transaction and do a rollback, the table is "half
> dropped", the table is gone but you cannot create a new table with the same
> name, nor can you drop it again.
>
> You have to manually go to the data/base/database directory and recreate
> any necessary referenced files (just empty files will do). Only then can
> you drop the table properly.
>
> ------------------------------------------------------------------
> Please describe a way to repeat the problem.   Please try to provide a
> concise reproducible example, if at all possible:
> ----------------------------------------------------------------------
>
> CREATE TABLE SESSION (
> SES_ID SERIAL,
> SES_UID INT4,
> SES_STR CHAR(40),
> SES_STAT CHAR,
> SES_SDATE DATETIME,
> SES_EDATE DATETIME,
> SES_ADATE DATETIME
> );
> begin transaction;
> drop table session;
> rollback;
> (if you do commit it's ok)
>
> select * from session;
>
> ERROR:  mdopen: couldn't open session: No such file or directory
>
> create table session (a int4);
> ERROR:  Relation 'session' already exists
> (Uh Oh)
> lylyeoh=> drop table session;
>
> ERROR:  mdopen: couldn't open session: No such file or directory
> (Oh no!)
>
> So create empty tablefile in data/base/lylyeoh directory
> [postgres bash shell]$ > session
>
> lylyeoh=> drop table session;
> ERROR:  mdopen: couldn't open session_ses_id_key: No such file or directory
>
> So create empty indexfile in data/base/lylyeoh directory
> [postgres bash shell]$ > session_ses_id_key
>
> lylyeoh=> drop table session;
>
> DROP
> (YEEHA! DIEDIEDIE!)
> lylyeoh=> create table session (a int4);
> CREATE
>
> Phew :).
>
> Not a big deal since I won't be doing drop tables in transactions. I only
> encountered this after just installing 6.5.2 and doing some tests on
> PostgreSQL transaction handling.
>
>
> If you know how this problem might be fixed, list the solution below:
> ---------------------------------------------------------------------
> Only know how to fix the damage. Not the bug. I suspect the rollback
> doesn't check that there's a "drop table" and does something that it
> shouldn't for that case.
>
> Are there other similar problems for drop sequence/index and stuff?
>
> Cheerio,
>
> Link.
>
>
>
> ************
>
>


--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] 6.5.2 broken on alpha/Tru64 Unix 4.0d/cc
Next
From: Bruce Momjian
Date:
Subject: Re: [BUGS] 6.5.2 broken on alpha/Tru64 Unix 4.0d/cc