From: | Stanislas Pinte <stan(dot)pinte(at)wanadoo(dot)be> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: DB crash on "drop table" interruption |
Date: | 2001-02-01 09:11:36 |
Message-ID: | 5.0.2.1.0.20010201100649.00a9ca40@195.74.212.23 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
-------------------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2001-02-01 09:43:07 | Re: Re: DB crash on "drop table" interruption |
Previous Message | Davidd | 2001-02-01 05:54:06 | Bug Report #25 executeUpdate returns 1 |