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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-sql by date

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