Re: Problem with dropping a tablespace

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

In response to

Responses

Browse pgsql-general by date

  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