Re: Re: DB crash on "drop table" interruption - Mailing list pgsql-bugs

From Hiroshi Inoue
Subject Re: Re: DB crash on "drop table" interruption
Date
Msg-id 3A792FAB.7DABCAF2@tpf.co.jp
Whole thread Raw
In response to DB crash on "drop table" interruption  (Stanislas Pinte <stan.pinte@wanadoo.be>)
Responses Re: Re: DB crash on "drop table" interruption
List pgsql-bugs
Stanislas Pinte wrote:
>
>          At 08:28 AM 2/1/01 +0900, you wrote:
> >Stanislas Pinte wrote:
> > >
> > > hello,
> > >
> > > I just had a DB crash when interrupting manually a drop table operation,
> > > and when interrupting manually (using kill) a vacuumdb operation. Is it
> > > normal, or is it a bug?
> > >
> >
> >What does the DB crash mean ?
>
> The DB crash doesn not mean a backend crash. It means the lost of 80% of
> the tables of the database.
>

Oops I negelected to ask your PostgreSQL version.

> here is the scenario:
>
> 1: I initiated a "drop table mytable" operation.
> 2: It started to took 15 minutes, then I decided that laybe users were
> using this table
> 3: I killed the postgresql process.

Which process did you kill, the postmaster or other backends ?

> 4: I opened pgsql

Did you start a postmaster ?

> 5: I listed the tables ..."mytable" still there
> 6: I issue a drop table again, after having restarted the backend (not
> properly...a "kill" then a "postmaster start ")
> 7: the drop table doesn't work, even if the table "mytable" still appears.
> 8: I issue a "vacuumdb"...take hours, and stays blocked on my problematic table
> 9: I re-killed the back-end.
> 10: I started the DB: only four tables left...mytable and a lot of others
> have disappeared.
>

What does "select relname from pg_class;" show ?

Regards,
Hiroshi Inoue

pgsql-bugs by date:

Previous
From: Stanislas Pinte
Date:
Subject: Re: DB crash on "drop table" interruption
Next
From: Stanislas Pinte
Date:
Subject: Re: Re: DB crash on "drop table" interruption