Horton
Menu

Thread

  1. DB crash on "drop table" interruption

    Stanislas Pinte <stan.pinte@wanadoo.be> — 2001-01-31T21:53:52Z

    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?

thanks a lot,

STan


-------------------------------------------------------

Stanislas Pinte
Software engineer - Trademine-europe
Tel: 00 32 486 67 78 86
Fax: 00 32 2 706 59 34

-------------------------------------------------------

  2. Re: DB crash on "drop table" interruption

    Inoue, Hiroshi <inoue@tpf.co.jp> — 2001-01-31T23:28:25Z

    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 ?

Regards,
Hiroshi Inoue

  3. Re: DB crash on "drop table" interruption

    Stanislas Pinte <stan.pinte@wanadoo.be> — 2001-02-01T09:11:36Z

             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.

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.
4: I opened pgsql
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.

>Regards,
>Hiroshi Inoue

-------------------------------------------------------

Stanislas Pinte
Software engineer - Trademine-europe
Tel: 00 32 486 67 78 86
Fax: 00 32 2 706 59 34

-------------------------------------------------------

  4. Re: Re: DB crash on "drop table" interruption

    Inoue, Hiroshi <inoue@tpf.co.jp> — 2001-02-01T09:43:07Z

    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

  5. Re: Re: DB crash on "drop table" interruption

    Stanislas Pinte <stan.pinte@wanadoo.be> — 2001-02-01T09:47:43Z

    At 06:43 PM 2/1/01 +0900, Hiroshi Inoue wrote:
>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.


Postgres 7.0.3 running on Solaris 7.

>
> > 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 ?

the backends, unfortunately.



> > 4: I opened pgsql
>
>Did you start a postmaster ?


yes.


> > 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 ?

I rebuild the DB from a backup now, but ot showed only a very small subset 
of all the tables...



>Regards,
>Hiroshi Inoue

-------------------------------------------------------

Stanislas Pinte
Software engineer - Trademine-europe
Tel: 00 32 486 67 78 86
Fax: 00 32 2 706 59 34

-------------------------------------------------------

  6. Re: Re: DB crash on "drop table" interruption

    Inoue, Hiroshi <inoue@tpf.co.jp> — 2001-02-01T09:58:58Z

    Stanislas Pinte wrote:
> 
> At 06:43 PM 2/1/01 +0900, Hiroshi Inoue wrote:
> >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.
> 
> Postgres 7.0.3 running on Solaris 7.
> 
> >
> > > 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 ?
> 
> the backends, unfortunately.
> 
> > > 4: I opened pgsql
> >
> >Did you start a postmaster ?
> 
> yes.
> 
> > > 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 ?
> 
> I rebuild the DB from a backup now, but ot showed only a very small subset
> of all the tables...
> 

What does "rebuild" mean and What does
"ls -l $PGDATA/base/your_dbname" show ?

Regards,
Hiroshi Inoue