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??
pgsql-novice by date
|Next:||From: Tom Lane||Date: 2004-03-27 17:00:57|
|Subject: Re: problem (bug?) when killing client program |
|Previous:||From: Aarni Ruuhimäki||Date: 2004-03-27 13:23:14|
|Subject: Re: Upgrading PostgreSQL|