Re: Error exits (Re: [HACKERS] Open 6.5 items)
От | Vadim Mikheev |
---|---|
Тема | Re: Error exits (Re: [HACKERS] Open 6.5 items) |
Дата | |
Msg-id | 3756C278.5A16DB4B@krs.ru обсуждение исходный текст |
Ответ на | Error exits (Re: [HACKERS] Open 6.5 items) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > > Vadim Mikheev <vadim@krs.ru> writes: > >> It seems elog(FATAL) doesn't release allocated buffer pages. > >> It's OK ? > >> AFAIC elog(FATAL) causes proc_exit(0) and proc_exit() doesn't > >> call ResetBufferPool(). > > > Seems to me that elog(FATAL) should call siglongjmp(Warn_restart, 1), > > like elog(ERROR), but force exit in tcop main loop after > > AbortCurrentTransaction(). AbortTransaction() does pretty nice > > things like RelationPurgeLocalRelation(false) and DestroyNoNameRels()... > > Seems reasonable to me. It seems to me that elog(FATAL) means "this > backend is too messed up to continue, but I think the rest of the > backends can keep going." So we need to clean up our allocated > resources before quitting. abort() is for the cases where we think > shared memory may be corrupted and everyone must bail out. We might > need to revisit the uses of each routine and make sure that different > error conditions are properly classified. > > Of course, if things *are* messed up then trying to AbortTransaction > might make it worse. How bad is that risk? Don't know. I think that we have no time to fix this in 6.5, -:( Vadim
В списке pgsql-hackers по дате отправления: