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@the-infinite.org]
Sent: Monday, March 18, 2002 1:28 PM
To: Jason Williams
Cc: pgsql-general@postgresql.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/