RE: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea
От | Mikheev, Vadim |
---|---|
Тема | RE: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A234D3284@sectorbase1.sectorbase.com обсуждение исходный текст |
Ответы |
Re: SIGTERM -> elog(FATAL) -> proc_exit() is probably a bad idea
|
Список | pgsql-hackers |
> > I've tried to move "dangerous" ops with non-zero probability of > > elog(ERROR) (eg new file block allocation) out of crit sections. > > Anyway we need in ERROR-->STOP for safety when changes > > aren't logged. > > Why is that safer than just treating an ERROR as an ERROR? > It seems to me there's a real risk of a crash/restart loop if we > force a restart whenever we see an xlog-related problem. Why don't we elog(ERROR) in assert checking but abort? Consider elog(STOP) on any errors inside critical sections as assert checking. Rule is simple - validate operation before applying it to permanent storage - and it's better to force any future development to follow this rule by any means. It's very easy to don't notice ERROR - it's just transaction abort and transaction abort is normal thing, - but errors inside critical sections are *unexpected* things which mean that something totally wrong in code. As for crash/restart loop, Hiroshi rised this issue ~month ago and I was going to avoid elog(STOP) in AM-specific redo functions and do elog(LOG) instead, wherever possible, but was busy with CRC/backup stuff - ok, I'll look there soon. Vadim
В списке pgsql-hackers по дате отправления: