From: | Oliver Siegmar <o(dot)siegmar(at)vitrado(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Problem with dropping a tablespace |
Date: | 2005-08-02 17:42:57 |
Message-ID: | 200508021942.58112.o.siegmar@vitrado.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tuesday 02 August 2005 18:42, Tom Lane wrote:
> > 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 don't know that for sure, but I can't remember having created and dropped an
other database within this tablespace.
> 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.
At which stage this pg_database entry gets created? I'm very sure, that there
was plenty of free disk space at the time of 'CREATE TABLE' statement. The
space ran out gigabytes after starting pg_restore.
I did a hexdump on the files within the tabelspace directory...no business
data at all, only postgres internals (I saw a lot of function names and
datatypes).
Let me know if I shall dig more information...otherwise I'm happy if I can
safely remove the directory.
Best
Oliver
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Armbrust | 2005-08-02 17:44:59 | Re: [BUGS] BUG #1552 followup |
Previous Message | Ragnar Hafstað | 2005-08-02 17:37:45 | Re: indexes are fucked |