Re: always forced restart after status 139?

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: always forced restart after status 139?
Дата
Msg-id 200203182043.g2IKh6E08121@saturn.janwieck.net
обсуждение исходный текст
Ответ на Re: always forced restart after status 139?  ("Jason Williams" <jwilliams@wc-group.com>)
Список 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@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/
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>


--

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



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


В списке pgsql-general по дате отправления:

Предыдущее
От: "Jason Williams"
Дата:
Сообщение: Re: always forced restart after status 139?
Следующее
От: Joep deVocht
Дата:
Сообщение: Small question