Skip site navigation (1) Skip section navigation (2)

Re: Error in recent pg_dump change (coverity)

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Error in recent pg_dump change (coverity)
Date: 2006-05-28 17:38:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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.

Alvaro Herrera                      
The PostgreSQL Company - Command Prompt, Inc.

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-05-28 17:40:09
Subject: Re: Error in recent pg_dump change (coverity)
Previous:From: Tom LaneDate: 2006-05-28 17:07:06
Subject: Re: Error in recent pg_dump change (coverity)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group