Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea
Date
Msg-id 3A62510F.F6DECF88@tpf.co.jp
Whole thread Raw
In response to RE: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hmm, I've seen neither my posting nor your reply
on hackers ML.

Tom Lane wrote:
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> Why?  What difference do you see in the nature of the critical sections?
> >> They all look the same to me: hold off cancel/die response.
> 
> > I've thought that the main purpose of CRIT_SECTION is to
> > force redo recovery for any errors during the CRIT_SECTION
> > to complete the critical operation e.g. bt_split().
> 
> How could it force redo?

Doesn't proc_exit(non-zero) force shuttdown recovery ?
AFAIK, Postgres doesn't have a rollback recovery 
functionality yet.

> Rollback, maybe, but that should happen
> anyway.
> 
> > Note that elog(ERROR/FATAL) is changed to elog(STOP) if Critical
> > SectionCount > 0.
> 
> Not in current sources ;-).
>

Oh you removed the code 20 hours ago. AFAIK, the (equivalent)
code has lived there from the first appearance of CRIT_SECTION.
Is there any reason to remove the code ?
Regards.
Hiroshi Inoue


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Must implement PQnotifyFree()
Next
From: Tom Lane
Date:
Subject: Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea