Oliver Siegmar <o.siegmar@xxxxxxxxxx> writes:
> On Tuesday 02 August 2005 17:01, Michael Fuhr wrote:
>> Hmmm...based on the file names, it looks like the directory contains
>> only system tables. Do you know what database this was?
> Yes, a business database - not a system one. The database were created using
> template0.
>> Did you explicitly drop it, or is its disappearance (or appearance) a
>> mystery?
> I dropped the database with 'DROP DATABASE xxx;' without any problems (after
> the tablespace run out of space).
How exactly do you know that OID 595675173 is the database you dropped,
and not that of some other DB?
I'm theorizing that the scenario went like this:
CREATE DATABASE starts to create a database, for which it
assigns the OID 595675173.
Copying the template database goes fine. (If we'd run out of
space in this step, we'd have removed the partially copied
directories before reporting failure.)
While trying to make the pg_database entry for the new database,
we run out of space and fail.
There isn't any provision for removing the copied data if we fail at
late stages of the CREATE process :-(. I'm not sure it's possible to
plug this hole completely, but we could at least catch any error up
to the end of createdb() by wrapping all that code in a
PG_TRY/PG_RECOVER block. With the recent shared dependency patch,
our exposure to an out-of-space failure at this stage has gone up by
orders of magnitude because so many more catalog rows need to be added.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
