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 EKEJJICOHDIEMGPNIFIJCEMODEAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > Isn't it appropriate to call a diffrent macro using a separate 
> > CriticalSectionCount variable in newly added places ?
> 
> 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(). Note that
elog(ERROR/FATAL) is changed to elog(STOP) if Critical
SectionCount > 0.  Postgres 7.1 stll lacks an undo functionality
and AbortTransaction() does little about rolling back the
transaction. PostgreSQL seems to have to retry the critical
operation by running a redo recovery after killing all backends.

Regards.
Hiroshi Inoue


pgsql-hackers by date:

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