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/
