DB crash on "drop table" interruption

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

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

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

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

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

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

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