Re: always forced restart after status 139?

Thanks Dominic.

Point taken and understood.

The problem is this: we are planning to make this database for a commercial
website that will handle financial transactions. What will happen if the
database receives a seg fault and another user of the database is in the
middle of submitting a "critical" update? I'm assuming it will rollback
gracefully?

Does anyone know what the exact behavior is in this situation?

Thanks,

Jason

-----Original Message-----
From: Dominic J. Eidson [mailto:sauron(at)the-infinite(dot)org]
Sent: Monday, March 18, 2002 1:28 PM
To: Jason Williams
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] always forced restart after status 139?

On Mon, 18 Mar 2002, Jason Williams wrote:

> We are using Postgres 7.1 on RedHat Linux 7.1.
>
> When calling a C function in a shared library (*.so), if you get a
> segmentation fault (status 139), the log indicates that the database will
> shut down and then restart in a few seconds.
>
> My question is, does this always have to happen? Is postgres capable of
> just logging the seg fault, but not affecting all the users on the
database
> by restarting?

Because (the nature of) a SIGSEGV, you can't trust any data remaining in
memory - what if the crash was caused by corrupt data in memory?

This is why PostgreSQL completely shuts down, and re-starts back up.

Allowing any part of PostgreSQL to continue (especially since there's data
in SHM that's important) would be a bad idea, since you have no idea who
caused the SIGSEGV.

--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" -
Gimli
----------------------------------------------------------------------------
---
http://www.the-infinite.org/
http://www.the-infinite.org/~dominic/