Re: Error in recent pg_dump change (coverity)
От | Bruce Momjian |
---|---|
Тема | Re: Error in recent pg_dump change (coverity) |
Дата | |
Msg-id | 200605281740.k4SHe9R08155@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Error in recent pg_dump change (coverity) (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
Alvaro Herrera wrote: > Tom Lane wrote: > > Alvaro Herrera <alvherre@commandprompt.com> writes: > > > Tom Lane wrote: > > >> Hm. But I think we'd *like* it to segfault; the idea is to make the > > >> user's programming error as obvious as possible. Is it worth the > > >> trouble to just zero out the pointer members of the PGresult? > > > > > There are only five of them; four need to be zeroed out. > > > > Works for me. Please commit, as I'm about to do some further work in > > those files and would rather not have to merge ... > > Done. They were actually four, not five. The one I mistakingly though > was one was the notice processor hooks. > > The case Martijn was saying would be warned about by the memset > approach, setting ntuples to 0, would actually be handled as a segfault, > because functions like check_field_number actually follow > res.noticeHooks pointer! ISTM we would just segfault at that point. Agreed. Anything to catch more errors is good. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: