From: | "Marcus Andree S(dot) Magalhaes" <marcus(dot)magalhaes(at)vlinfo(dot)com(dot)br> |
---|---|
To: | <pgsql-novice(at)postgresql(dot)org> |
Subject: | problem (bug?) when killing client program |
Date: | 2004-03-27 13:52:40 |
Message-ID: | 63417.200.174.148.100.1080395560.squirrel@webmail.webnow.com.br |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
I don't know if this is a bug or feature, but here goes the report.
When trying to backup a table that lives on a database with the same
name, I ended issuing the wrong command and, instead, started a
full dump of a multigigabyte database with pg_dump.
A couple seconds later, just pressed Ctrl-C. The pg_dump, as desired,
quit. After that, the follwing line was found on `ps` output:
postgres 22332 26.4 4.5 96264 69980 pts/2 R 10:32 3:24 postgres:
postgres <dbname> [local] COPY
The pg_dump process was confirmed killed and the uptime output, at the
same time was:
10:41:02 up 14 days, 19:56, 3 users, load average: 20.11, 11.48, 10.28
Realizing that the things weren't quite right, sent a SIGTERM (kill with
no flags) to the PID 22332.
What happened? The entire backend crashed and burned in enormous flames.
We're using postgres 7.4.1 on a Linux/i386 SMP machine.
Ok, it wasn't nice to start a full backup when it wasn't the real intention,
but shouldn't the backend process deal with these situations without
crashing down and causing minors data loss in the recovery??
TIA.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-03-27 17:00:57 | Re: problem (bug?) when killing client program |
Previous Message | Aarni Ruuhimäki | 2004-03-27 13:23:14 | Re: Upgrading PostgreSQL |