Re: Effect of a kill -9 on postgres

The only time "kill -9" should be a data corruption issue is if you kill the
postMASTER (not just a backend) then remove the postmaster.pid file from the
datadir and relaunch the postmaster without first making sure the worker
backends are all shut down.

You need to load the shotgun, aim it carefully at your foot, take the safety
off and pull the trigger. It's not easy.

A "kill -9" shouldn't even cause problems if you're running on unsafe write
cached storage or (afaik) with fsync=off. Though for other reasons you
should never be doing either without streaming replication, good backups,
and a willingness to life some data.

On Aug 8, 2011 9:01 AM, "Royce Ausburn" <royce(dot)ml(at)inomial(dot)com> wrote:
> Hi all,
>
> A few days ago one of our postgres (8.3.12) servers was a bit unhappy, and
someone decided to try a kill -9 on a backend process after a kill (TERM)
was ineffective. I've read many times in the past that a kill -9 can be
pretty hazardous to a postgres' health, and now it seems I get to see first
hand how hazardous it really is :(
>
> Fortunately postgres seems to have detected the -9 signal and brought the
system down:
>
> 2011-08-05 17:17:53 EST redacted.com 10.3.0.3(39556) admin(at)redacted(dot)comWARNING: terminating connection because of crash of another server process
> 2011-08-05 17:17:53 EST redacted.com 10.3.0.3(39556) admin(at)redacted(dot)comDETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
> 2011-08-05 17:17:53 EST redacted.com 10.3.0.3(39556) admin(at)redacted(dot)comHINT: In a moment you should be able to reconnect to the database and repeat
your command.
>
> After the barrage of those messages, there:
>
> 2011-08-05 17:17:54 EST LOG: all server processes terminated;
reinitializing
> 2011-08-05 17:17:55 EST LOG: database system was interrupted; last known
up at 2011-08-05 17:15:33 EST
> 2011-08-05 17:17:55 EST LOG: database system was not properly shut down;
automatic recovery in progress
> 2011-08-05 17:17:55 EST LOG: redo starts at 208/5013A758
> 2011-08-05 17:17:55 EST LOG: record with zero length at 208/51497498
> 2011-08-05 17:17:55 EST LOG: redo done at 208/51497468
> 2011-08-05 17:17:55 EST LOG: last completed transaction was at log time
2011-08-05 17:17:52.709539+10
> 2011-08-05 17:18:03 EST LOG: autovacuum launcher started
> 2011-08-05 17:18:03 EST LOG: database system is ready to accept
connections
>
>
> For each of the other backend processes.
>
> I'm a bit worried about corruption and would like to know:
>
> - Is postgres 8.3.12 susceptible to corruption when a backend process is
-9'd?
>
> - How do we confirm that there has been no corruption?
>
> We have nightly backups that dump every database in the cluster, and
looking over postgres' logs I can't see any errors that might point to
corruption... I guess that's a good sign - is there anything else I can look
in to?
>
> Thanks very much,
>
> --Royce
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general