RE: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea
От | Hiroshi Inoue |
---|---|
Тема | RE: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea |
Дата | |
Msg-id | EKEJJICOHDIEMGPNIFIJCEMODEAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea
|
Список | 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 по дате отправления: