Re: always forced restart after status 139?

From: Jan Wieck <janwieck(at)yahoo(dot)com>
To: Jason Williams <jwilliams(at)wc-group(dot)com>
Cc: "Dominic J(dot) Eidson" <sauron(at)the-infinite(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: always forced restart after status 139?
Date: 2002-03-18 20:43:06
Message-ID: 200203182043.g2IKh6E08121@saturn.janwieck.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jason Williams wrote:
> 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?

First of all, you don't allow development work on the same
system your production runs on. Doing so implies that the
data is not critical to you.

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

Nobody can tell for sure. In almost all cases, yes, the
rollback would be gracefully. But the fault could've
corrupted the stack of the failing backend, causing it to
execute arbitrary code. How does someone predict what
arbitrary code will do?

Jan

>
> 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/
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Eric Lee Green 2002-03-18 23:01:27 Performance issues
Previous Message Jarosław Jankowski 2002-03-18 20:39:30 How can I know that record is locked?