Обсуждение: DB crash on "drop table" interruption
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 -------------------------------------------------------
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