Skip site navigation (1) Skip section navigation (2)

Re: What is happening?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Carolyn Lu Wong <carolyn(at)kss(dot)net(dot)au>
Cc: "pgsql-sql(at)postgresql(dot)org" <pgsql-sql(at)postgresql(dot)org>
Subject: Re: What is happening?
Date: 2000-08-03 15:05:09
Message-ID: 8036.965315109@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-sql
Carolyn Lu Wong <carolyn(at)kss(dot)net(dot)au> writes:
> I was trying to dump data, drop then recreate table, and import data
> back to the table. There were errors during the process and the
> transaction was not committed.

> ERROR: mdopen: couldn't open accounts: No such file or directory.

Rolling back a "drop table" doesn't work at the moment :-(, because the
physical table file is deleted at the moment of DROP.  When you aborted
the transaction, the system-table rows for the table came back to life,
but the file didn't.

You can get back into a consistent state by creating a dummy table file
by hand, eg do

	touch .../data/base/yourdb/accounts

and then you will be able to do the DROP TABLE.  After that you can
recreate and reload the table from the data file (which I hope you
kept...)

One of the things on the to-do list is to postpone physical delete of
table files till COMMIT, so that a DROP can be rolled back safely.
(Not likely for 7.1, but maybe for 7.2.)  In the meantime, it's probably
best not to do DROP inside a transaction.  7.0 will emit a notice
warning you about this, but earlier versions don't.

BTW, ALTER TABLE RENAME in a transaction is equally dangerous for the
same kind of reason.

			regards, tom lane

In response to

pgsql-sql by date

Next:From: Tom LaneDate: 2000-08-03 15:20:44
Subject: Re: a question about dates and timestamp
Previous:From: Antti LinnoDate: 2000-08-03 13:49:34
Subject: Extracting data by months

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group