Error exits (Re: [HACKERS] Open 6.5 items)
От | Tom Lane |
---|---|
Тема | Error exits (Re: [HACKERS] Open 6.5 items) |
Дата | |
Msg-id | 6562.928432402@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Open 6.5 items (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
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? regards, tom lane
В списке pgsql-hackers по дате отправления: